Re: get_cache and multiple caches

[Curtis Maloney]

Bit of a rambling, thinking-out-loud-ish post...

Whilst it's conceivable  some cache backend will have the smarts to
multiplex requests on a single connection, I suspect that's more the
exception than the case.

However, that doesn't mean the cache backend can't be left with the
opportunity to manage per-thread connections.  Obviously, the default would
be one per thread.

The situation is complicated with the "ad-hoc config" option.  Otherwise,
each cache backend could have a factory method, where the cares of thread
locality can be managed.  You'd just tell it the name, and it would take
care of the rest.

Of course, that could be simplified by just always creating a new instance
when more than just a name is provided. [or a "force new" keyword is
passed].

--
Curtis



On 1 September 2013 22:24, Florian Apolloner  wrote:

> Hi,
>
>
> On Sunday, September 1, 2013 4:34:54 AM UTC+2, Curtis Maloney wrote:
>>
>> I've a possible solution - https://github.com/funkybob/**
>> django/compare/simple_caches
>>
>> Basically, the existing API and behaviours are still available through
>> get_cache, but you can avoid duplicate instances of caches using
>> django.core.cache.caches[name]
>>
>
> As noted on the ticket (https://code.djangoproject.com/ticket/21012), I
> think this needs some more brainstorming (preferably on this ml) before we
> introduce a new pulbic API to access a cache. My main concern is: does it
> even make sense to share the cache connection between threads? eg what
> happens if two threads want to read a value from the cache, will one thread
> block till python-memcached returned the value for the other thread?
>
> Cheers,
> Florian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Order of INSTALLED_APPS

[Marc Tamlyn]

I don't think it would break South installations as custom app commands
will always override builtins. Could you open a ticket for that? The
inconsistency is problematic. Obviously it would be backwards incompatible,
but we need to gauge the size of the impact.

Marc
On 1 Sep 2013 21:31, "Kevin Christopher Henry"  wrote:

> Sorry to be late to this thread, I just came across it.
>
> There's another place where the order of INSTALLED_APPS matters:
> management commands. Management commands associated with apps that come
> later in INSTALLED_APPS will replace those with the same name that are
> listed earlier. I can't find this documented anywhere, but a look at the
> code confirms it. South, for example, takes advantage of this to override
> the syncdb command (and hints at the ordering issue when the documentation
> says: "add 'south' to the end of INSTALLED_APPS").
>
> So a documentation update should probably note this specifically in the
> management documentation, as well as mentioning it in the box for
> INSTALLED_APPS. (I also think static files should also be mentioned in the
> box, since as Aymeric points out that is another area dependent on the
> order of apps.)
>
> One thing that's unfortunate is that the semantics of ordering for
> management commands is opposite that of the other cases. For templates,
> static files, and translations, listing an app *first *gives it
> precedence, whereas with management commands it's listing it *last.*Ideally 
> this would be changed so that management commands were consistent
> with the other cases, but that would create serious backwards compatibility
> issues. Like, breaking everyone's South installation. :-O
>
> Cheers,
> Kevin
>
>
> On Wednesday, August 14, 2013 5:26:47 AM UTC-4, Stefano Crosta wrote:
>>
>> Done! 
>> https://code.**djangoproject.com/ticket/**20914#ticket
>>
>> thanks!
>>
>> On Tuesday, August 13, 2013 12:20:48 PM UTC+2, Aymeric Augustin wrote:
>>>
>>> 2013/8/13 Stefano Crosta 
>>>
 My proposal would then be to simply add another box to the
 https://docs.**djangoproject.com/en/dev/ref/**settings/#installed-apps
  to
 say "order matters" once more and link the other two pages for translations
 and templates.
 *if you think this would* help I could do it as well as a ticket. To
 save everybody's time no answer will mean it's not worth it!

>>>
>>> Yes, please file one, and include a link to this discussion.
>>>
>>> --
>>> Aymeric.
>>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Order of INSTALLED_APPS

[Kevin Christopher Henry]

Sorry to be late to this thread, I just came across it.

There's another place where the order of INSTALLED_APPS matters: management 
commands. Management commands associated with apps that come later in 
INSTALLED_APPS will replace those with the same name that are listed 
earlier. I can't find this documented anywhere, but a look at the code 
confirms it. South, for example, takes advantage of this to override the 
syncdb command (and hints at the ordering issue when the documentation 
says: "add 'south' to the end of INSTALLED_APPS").

So a documentation update should probably note this specifically in the 
management documentation, as well as mentioning it in the box for 
INSTALLED_APPS. (I also think static files should also be mentioned in the 
box, since as Aymeric points out that is another area dependent on the 
order of apps.)

One thing that's unfortunate is that the semantics of ordering for 
management commands is opposite that of the other cases. For templates, 
static files, and translations, listing an app *first *gives it precedence, 
whereas with management commands it's listing it *last.* Ideally this would 
be changed so that management commands were consistent with the other 
cases, but that would create serious backwards compatibility issues. Like, 
breaking everyone's South installation. :-O

Cheers,
Kevin


On Wednesday, August 14, 2013 5:26:47 AM UTC-4, Stefano Crosta wrote:
>
> Done! https://code.djangoproject.com/ticket/20914#ticket
>
> thanks!
>
> On Tuesday, August 13, 2013 12:20:48 PM UTC+2, Aymeric Augustin wrote:
>>
>> 2013/8/13 Stefano Crosta 
>>
>>> My proposal would then be to simply add another box to the 
>>> https://docs.djangoproject.com/en/dev/ref/settings/#installed-apps to 
>>> say "order matters" once more and link the other two pages for translations 
>>> and templates.
>>> *if you think this would* help I could do it as well as a ticket. To 
>>> save everybody's time no answer will mean it's not worth it!
>>>
>>
>> Yes, please file one, and include a link to this discussion.
>>
>> -- 
>> Aymeric. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get_cache and multiple caches

[Florian Apolloner]

Hi,

On Sunday, September 1, 2013 4:34:54 AM UTC+2, Curtis Maloney wrote:
>
> I've a possible solution - 
> https://github.com/funkybob/django/compare/simple_caches
>
> Basically, the existing API and behaviours are still available through 
> get_cache, but you can avoid duplicate instances of caches using 
> django.core.cache.caches[name]
>

As noted on the ticket (https://code.djangoproject.com/ticket/21012), I 
think this needs some more brainstorming (preferably on this ml) before we 
introduce a new pulbic API to access a cache. My main concern is: does it 
even make sense to share the cache connection between threads? eg what 
happens if two threads want to read a value from the cache, will one thread 
block till python-memcached returned the value for the other thread?

Cheers,
Florian 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Circular dependency in forms+views+models

[Curtis Maloney]

Given both the docs for get_absolute_url and reverse demonstrate using
string references only, I think adding in clarification of why it's
preferred is worthwhile.

I still find it surprising how often I need to tell people on #django to
not import models just to reference them in relation fields...

--
Curtis



On 1 September 2013 17:00, Jorge Cardoso Leitao wrote:

> The way I stumbled across this problem was:
>
> 1. views imports models and forms (both are normally needed)
>
> 2. forms imports models (for ModelForm)
>
> 3. models imports views (for get_absolute_url), e.g.:
>
> *import views*
> *class MyModel(models.Model):*
> * get_absolute_url(reverse(views.myview))*
>
> which leads to a circular dependency of the form
> views->forms->models->views.
>
> I searched and there are some questions raised in stackoverflow about it,
> e.g. 
> this
> , this
> .
> This is avoided by removing one of the imports, and in this
> case the candidate is 3., replacing it with a string (e.g. 'views.myview').
>
> I propose that we add a note on the documentation of 
> get_absolute_url
> explaining that get_aboslute_url should be coded by returning reverses of
> strings and
> not of functions or classes to avoid circular dependencies.
>
> There is a ongoing 
> thread
>  about
> get_absolute_url and I think these problems are
> somewhat related: this circular dependency is a valid mistake from a
> Django user because models are depending on views, views on forms, forms
> on models.
>
> Another reason why I think this should be documented is that circular
> dependencies
> are difficult to debug, specially when they occur after modules are
> imported like *import module.*
>
> This also makes the documentation more consistent: Foreign 
> Key 
> already
> warns about circular dependencies:
>
> "This sort of reference can be useful when resolving circular import
> dependencies between two applications."
>
> In summary, I agree that the url's "anti-circular dependency" is correctly
> fixed from the implementation point of view by allowing strings,
> what I'm proposing is just to document why users should use it, i.e. what
> they are useful for, specially in the models' get_absolute_url.
>
> If no one objects, I can do this.
>
> Regards,
> Jorge
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Circular dependency in forms+views+models

[Jorge Cardoso Leitao]

The way I stumbled across this problem was:

1. views imports models and forms (both are normally needed)

2. forms imports models (for ModelForm)

3. models imports views (for get_absolute_url), e.g.:

import views
class MyModel(models.Model):
get_absolute_url(reverse(views.myview))

which leads to a circular dependency of the form views->forms->models->views.

I searched and there are some questions raised in stackoverflow about it, e.g. 
this, this.
This is avoided by removing one of the imports, and in this
case the candidate is 3., replacing it with a string (e.g. 'views.myview').

I propose that we add a note on the documentation of get_absolute_url
explaining that get_aboslute_url should be coded by returning reverses of 
strings and
not of functions or classes to avoid circular dependencies.

There is a ongoing thread about get_absolute_url and I think these problems are
somewhat related: this circular dependency is a valid mistake from a
Django user because models are depending on views, views on forms, forms on 
models.

Another reason why I think this should be documented is that circular 
dependencies
are difficult to debug, specially when they occur after modules are imported 
like import module.

This also makes the documentation more consistent: Foreign Key already warns 
about circular dependencies:

"This sort of reference can be useful when resolving circular import 
dependencies between two applications."

In summary, I agree that the url's "anti-circular dependency" is correctly 
fixed from the implementation point of view by allowing strings,
what I'm proposing is just to document why users should use it, i.e. what they 
are useful for, specially in the models' get_absolute_url.

If no one objects, I can do this.

Regards,
Jorge

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.