Re: Non-default managers in related field lookups
On Fri, Jun 1, 2012 at 8:53 AM, Jeremy Dunck wrote:
> It feels to me that each place that ._default_manager is mentioned
> here is a misfeature:
> https://github.com/django/django/blob/2cd516002d43cdc09741618f0a0db047ee6d78fd/django/db/models/fields/related.py
>
> As an example, we (Votizen) currently have some default managers which
> show subsets of all objects (published, for example).
>
> class Candidate(...):
> races = ManyToMany(Race, related_name='candidates')
>
> objects = CandidateWithPublishedRacesManager()
> objects_all = Manager()
>
> class Race(...):
> objects = PublishedRaceManager()
> objects_all = Manager()
>
> The intention here is that we show the blessed subset by default
> (mostly for the site), show more for admin, shell, scripts, etc.
>
> The trouble is this asymmetry:
>
> candidate_with_unpublished_races = Candidate.objects_all.all()[0]
>
> candidate_with_unpublished_races.races.all() !=
> Race.objects.filter(candidates=candidate_with_unpublished_races)
>
> This affects admin (because while we can control
> CandidateAdmin.queryset, we can't control Candidate.races). But it
> also comes as a surprise fairly often in general. Note that no error
> is raised, you just process a subset of the data you meant to,
> generally.
>
> (We have considered instead adding manager methods for the site:
> Candidate.objects.for_site()..., but you see this has the same problem
> - assuming the default manager doesn't call that chained query
> method.)
>
>
> OK, for a solution, here's an API I think would remove the asymmetry:
>
>
> Candidate.context('site') would return a manager depending on the
> requested context.
> (or perhaps Candidate.objects.using(context='site')... or
> Candidate.objects.context('site'))
>
> # get an instance while assigning ._state.context == 'site', similar
> to ._state.db
> candidate_with_unpublished_races = Candidate.context('site')
>
> # the router grows a method to help decide what to do on a per-model basis.
> class DatabaseRouter(object):
> ...# as now except, for example:
> def manager_for_context(self, context, model_class):
> # returns a manager
> # e.g.
> return getattr(model_class, "objects_%s" % context)
> # could also by dynamically constructed.
>
> (It seems to me the router is the natural place to have
> project-specific customization of what happens with managers, though
> perhaps some community norms would be needed
>
> And then perhaps models can have defaults, as they do DBs:
>
> class FooModel(Model):
> ...
> class Meta:
> context = "site"
>
> class FooAdmin(Admin):
> model = FooModel
>
> class Meta:
> context = "admin"
>
> For backwards-compatibility, any model without a context specified in
> meta gets "default", and the default database manager always resolves
> to model_class._default_manager.
>
> For app composition, there is still value in the concept of a default
> manager, though I'm not entirely clear how this fits together.
>
> Perhaps Frob.objects would resolve to some manager based on the default
> context,
> unless .objects had been explicitly assigned to be a vanilla manager
> (much as a queryset resolves the db via the router unless .using(db=)
> has been used).
>
> Note, I'm not entirely happy with this, but it gives something to start from.
>
> Thoughts?
Is this really something that's going to be able to be managed at the
routing level? It seems to me that the decision about exactly which
set of objects you want returned needs much finer control that a
router method will allow.
It might not happen in your case specifically, but I wouldn't think it
would be unusual to have a single view in which both "full" list and
the "filtered" list are retrieved. If you're working with the managers
directly, that's easy:
selected_canddiates = Candidate.objects.all()
all_candidates = Candidate.objects_all.all()
but if you want to go through the relation for objects related to a
specific race, it's not:
selected_canddiates = race.candidates.all()
all_candidates = race.candidates.all() # this won't give the right results...
If I'm understanding your proposal correctly, I'd need to either tweak
the _state of race between the two calls to switch the context, or
write a router that was able to differentiate between the two uses
based on some other contextual cue (I'm not sure what could be
provided to give that differentiation, though).
The context switching might be possible with some utility methods or a
Python context managers, but it still seems like the wrong way to
affect control -- modifying an object's state so that it's default
behaviour changes, rather than explicitly requesting the behaviour
your want.
Here's a counter-proposal:
mycandidate.races is a descriptor. That descriptor implements
__get__() to return a RelatedObjectsManager that does the appropriate
filtering. The related objects manager is a standard manager that
allows calls to all(), filter() etc. Why not also imp
Re: Non-default managers in related field lookups
On Jun 1, 12:26 pm, Russell Keith-Magee
wrote:
> Is this really something that's going to be able to be managed at the
> routing level? It seems to me that the decision about exactly which
> set of objects you want returned needs much finer control that a
> router method will allow.
>
> It might not happen in your case specifically, but I wouldn't think it
> would be unusual to have a single view in which both "full" list and
> the "filtered" list are retrieved. If you're working with the managers
> directly, that's easy:
>
> selected_canddiates = Candidate.objects.all()
> all_candidates = Candidate.objects_all.all()
>
> but if you want to go through the relation for objects related to a
> specific race, it's not:
>
> selected_canddiates = race.candidates.all()
> all_candidates = race.candidates.all() # this won't give the right results...
>
> If I'm understanding your proposal correctly, I'd need to either tweak
> the _state of race between the two calls to switch the context, or
> write a router that was able to differentiate between the two uses
> based on some other contextual cue (I'm not sure what could be
> provided to give that differentiation, though).
>
> The context switching might be possible with some utility methods or a
> Python context managers, but it still seems like the wrong way to
> affect control -- modifying an object's state so that it's default
> behaviour changes, rather than explicitly requesting the behaviour
> your want.
>
> Here's a counter-proposal:
>
> mycandidate.races is a descriptor. That descriptor implements
> __get__() to return a RelatedObjectsManager that does the appropriate
> filtering. The related objects manager is a standard manager that
> allows calls to all(), filter() etc. Why not also implement __call__,
> and have __call__() return a new RelatedObjectsManager, bound to a
> different manager (as named in the arguments to call)?
>
> So, using your example:
>
> * race.candidates.all() would use _default_manager
>
> * race.candidates('objects_all').all() would use the objects_all manager
>
> * race.candidates('objects').all() would also use _default_manager
> (but explicitly)
>
> With some slightly neater manager naming, it becomes even easier to
> read. Consider the following example:
>
> class Person(…):
> people = Manager()
> men = MaleManager()
> women = FemaleManager()
>
> class Event(…):
> attendees = ManyToMany(Person, related_name='events')
> objects = Manager()
> confirmed = ConfirmedManager()
>
> then:
>
> all people: Person.people.all()
> all women: Person.women.all()
>
> all events: Event.objects.all()
> all confirmed events: Event.confirmed.all()
>
> all events being attended by the Person frank: frank.events.all()
> all confirmed events being attended by the Person frank:
> frank.events('confirmed').all()
>
> all people attending the brogrammer event: brogrammer.attendees.all()
> all men attending the brogrammer event: brogrammer.attendees('men').all()
>
> For my money, that's an explicit API that makes sense when reading the
> single query line, and doesn't require the interpolation of extra
> state/context from a router or some other context manager. It's also
> backwards compatible, because there won't be any existing code
> invoking __call__() on a manager.
>
> Russ %-)
+1.
Just as a bike-shedding thought: Would it be possible to have
frank.events.confirmed.all() as the syntax? I see this a tiny bit
cleaner. On the other hand it isn't explicit you can only use
the .confirmed only directly after the events, and there is the
possibility of clashing with queryset methods. The clash issue can be
solved by just using frank.events('clashing_name').all() instead of
frank.events.clashing_name.all() in the rare cases this is needed.
How would this work with prefetch_related? Maybe
prefetch_related('events__confirmed')? IMHO this is an important use
case, as there isn't currently any possibility to use different
filtering, ordering etc than the one given by the default related
manager.
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Non-default managers in related field lookups
On Fri, Jun 1, 2012 at 5:54 PM, Anssi Kääriäinen
wrote:
> On Jun 1, 12:26 pm, Russell Keith-Magee
> wrote:
>> Is this really something that's going to be able to be managed at the
>> routing level? It seems to me that the decision about exactly which
>> set of objects you want returned needs much finer control that a
>> router method will allow.
>>
>> It might not happen in your case specifically, but I wouldn't think it
>> would be unusual to have a single view in which both "full" list and
>> the "filtered" list are retrieved. If you're working with the managers
>> directly, that's easy:
>>
>> selected_canddiates = Candidate.objects.all()
>> all_candidates = Candidate.objects_all.all()
>>
>> but if you want to go through the relation for objects related to a
>> specific race, it's not:
>>
>> selected_canddiates = race.candidates.all()
>> all_candidates = race.candidates.all() # this won't give the right
>> results...
>>
>> If I'm understanding your proposal correctly, I'd need to either tweak
>> the _state of race between the two calls to switch the context, or
>> write a router that was able to differentiate between the two uses
>> based on some other contextual cue (I'm not sure what could be
>> provided to give that differentiation, though).
>>
>> The context switching might be possible with some utility methods or a
>> Python context managers, but it still seems like the wrong way to
>> affect control -- modifying an object's state so that it's default
>> behaviour changes, rather than explicitly requesting the behaviour
>> your want.
>>
>> Here's a counter-proposal:
>>
>> mycandidate.races is a descriptor. That descriptor implements
>> __get__() to return a RelatedObjectsManager that does the appropriate
>> filtering. The related objects manager is a standard manager that
>> allows calls to all(), filter() etc. Why not also implement __call__,
>> and have __call__() return a new RelatedObjectsManager, bound to a
>> different manager (as named in the arguments to call)?
>>
>> So, using your example:
>>
>> * race.candidates.all() would use _default_manager
>>
>> * race.candidates('objects_all').all() would use the objects_all manager
>>
>> * race.candidates('objects').all() would also use _default_manager
>> (but explicitly)
>>
>> With some slightly neater manager naming, it becomes even easier to
>> read. Consider the following example:
>>
>> class Person(…):
>> people = Manager()
>> men = MaleManager()
>> women = FemaleManager()
>>
>> class Event(…):
>> attendees = ManyToMany(Person, related_name='events')
>> objects = Manager()
>> confirmed = ConfirmedManager()
>>
>> then:
>>
>> all people: Person.people.all()
>> all women: Person.women.all()
>>
>> all events: Event.objects.all()
>> all confirmed events: Event.confirmed.all()
>>
>> all events being attended by the Person frank: frank.events.all()
>> all confirmed events being attended by the Person frank:
>> frank.events('confirmed').all()
>>
>> all people attending the brogrammer event: brogrammer.attendees.all()
>> all men attending the brogrammer event: brogrammer.attendees('men').all()
>>
>> For my money, that's an explicit API that makes sense when reading the
>> single query line, and doesn't require the interpolation of extra
>> state/context from a router or some other context manager. It's also
>> backwards compatible, because there won't be any existing code
>> invoking __call__() on a manager.
>>
>> Russ %-)
>
> +1.
>
> Just as a bike-shedding thought: Would it be possible to have
> frank.events.confirmed.all() as the syntax? I see this a tiny bit
> cleaner. On the other hand it isn't explicit you can only use
> the .confirmed only directly after the events, and there is the
> possibility of clashing with queryset methods. The clash issue can be
> solved by just using frank.events('clashing_name').all() instead of
> frank.events.clashing_name.all() in the rare cases this is needed.
True - but providing an API that avoids the clash in the first place
is preferable, IMHO.
That said, I'm not *strongly* opposed to .events.confirmed -- it just
tastes a bit funny. I'd rather not eat it, but if if everyone else
says I should…. :-)
> How would this work with prefetch_related? Maybe
> prefetch_related('events__confirmed')? IMHO this is an important use
> case, as there isn't currently any possibility to use different
> filtering, ordering etc than the one given by the default related
> manager.
That's a good point -- I hadn't thought of the consequences on
prefetch_related. I'm not wild about overloading the __ notation to
add the 'manager selector" interpretation. There are already
complications differentiating between aggregates, filter clauses,
related fields… I don't think we need to add another to this mix.
How about a kwarg to prefetch_related? For example:
person.prefetch_related('events', managers={'events': 'confirmed'})
or maybe just use kwargs directly:
person.prefetch_related(events='confirmed')
Re: Non-default managers in related field lookups
On Jun 1, 1:43 pm, Russell Keith-Magee
wrote:
> > Just as a bike-shedding thought: Would it be possible to have
> > frank.events.confirmed.all() as the syntax? I see this a tiny bit
> > cleaner. On the other hand it isn't explicit you can only use
> > the .confirmed only directly after the events, and there is the
> > possibility of clashing with queryset methods. The clash issue can be
> > solved by just using frank.events('clashing_name').all() instead of
> > frank.events.clashing_name.all() in the rare cases this is needed.
>
> True - but providing an API that avoids the clash in the first place
> is preferable, IMHO.
>
> That said, I'm not *strongly* opposed to .events.confirmed -- it just
> tastes a bit funny. I'd rather not eat it, but if if everyone else
> says I should…. :-)
As said, just bike-shedding. Lets go with the call-notation for now.
It is easy enough to bike-shed this more later. The call syntax is
clear enough, and it is explicit and should be easy to make that work.
> > How would this work with prefetch_related? Maybe
> > prefetch_related('events__confirmed')? IMHO this is an important use
> > case, as there isn't currently any possibility to use different
> > filtering, ordering etc than the one given by the default related
> > manager.
>
> That's a good point -- I hadn't thought of the consequences on
> prefetch_related. I'm not wild about overloading the __ notation to
> add the 'manager selector" interpretation. There are already
> complications differentiating between aggregates, filter clauses,
> related fields… I don't think we need to add another to this mix.
>
> How about a kwarg to prefetch_related? For example:
>
> person.prefetch_related('events', managers={'events': 'confirmed'})
>
> or maybe just use kwargs directly:
>
> person.prefetch_related(events='confirmed')
>
> If you start getting into multiple joins, it's going to get more
> complex; we might have to require a list of managers:
>
> person.prefetch_related(events__things=['confirmed', 'objects'])
This API has one problem: what if you want confirmed events in one
list, and then non-confirmed events in another?
I created a ticket where you could use R-objects for prefetch related.
The idea is that you can use any query you like, and fetch the related
objects to any attribute you like.
In short, the API is this:
SomeModel.objects.prefetch_related(
R('events', to_attr='confirmed_events',
qs=RelModel.confirmed.order_by('foo')),
)
You can chain those calls:
Person.objects.prefetch_related(
R('events', to_attr='confirmed_events',
qs=Event.confirmed.order_by('foo')),
R('confirmed_events__locations', to_attr='locations',
qs=Location.objects.order_by('name')),
)
Every Person object fetched fill have a list "confirmed_events", and
each confirmed event will have an attribute "locations".
Now, that API is a bit confusing to use, but on the other hand it
makes prefetch_related usable in very generic situations. Maybe a low-
level R-objects API for when you really need to do low-level stuff,
and then some syntax-sugar (like the events='confirmed') for the
common cases?
Of course, an API which allows the full R-object expression, but still
is easy to use for the events='confirmed' case would be perfect...
For details, see: #17001.
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Non-default managers in related field lookups
On Fri, 1 Jun 2012 17:26:54 +0800
Russell Keith-Magee wrote:
> Here's a counter-proposal: (…)
>
> So, using your example:
>
> * race.candidates.all() would use _default_manager
>
> * race.candidates('objects_all').all() would use the objects_all manager
>
> * race.candidates('objects').all() would also use _default_manager
> (but explicitly)
>
> (…)
>
> For my money, that's an explicit API that makes sense when reading the
> single query line, and doesn't require the interpolation of extra
> state/context from a router or some other context manager. It's also
> backwards compatible, because there won't be any existing code
> invoking __call__() on a manager.
FWIW, something very similar has been implemented in ticket #3871 [1],
patch `r17204-custom-reverse-managers.diff` [2], minus the __call__
notation. The patch in the ticket uses an explicit method named
`manager`, however using __call__ seems more elegant (+ 1).
Maybe the efforts from that patch can be revisited.
Best wishes,
Sebastian.
[1] https://code.djangoproject.com/ticket/3871
[2]
https://code.djangoproject.com/attachment/ticket/3871/r17204-custom-reverse-managers.diff
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
timezone.now() when USE_TZ=true
Hello! In django 1.4 with USE_TZ=true timezone.now() returns datetime.utcnow().replace(tzinfo=utc). Such datetime aware objects are handled properly in forms, templates and other places inside django framework. But when I prepare datetimes for ajax responses using strftime I always do localtime(timezone.now()). Same conversion I should do for any requests to external APIs which don't know about timezones. I couldn't find any discussions and arguments what timezone.now() should return. May be it will be more practical/comfortable for django users if timezone.now() will return localetime? What do you think about this? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/6w6WPwXo88IJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: timezone.now() when USE_TZ=true
On Jun 1, 10:27 am, Artem Andreev wrote: > Hello! > > In django 1.4 with USE_TZ=true timezone.now() returns > datetime.utcnow().replace(tzinfo=utc). > Such datetime aware objects are handled properly in forms, templates and > other places inside django framework. > But when I prepare datetimes for ajax responses using strftime I always do > localtime(timezone.now()). > Same conversion I should do for any requests to external APIs which don't > know about timezones. > > I couldn't find any discussions and arguments what timezone.now() should > return. > > May be it will be more practical/comfortable for django users if > timezone.now() will return localetime? > What do you think about this? The idea is that inside Python all datetimes are handled in time zone UTC. The rule is simple: you should keep the datetimes in UTC as long as you can. You should only convert the datetimes to other time zones if it is required by: - You need to display the data to users - You need to pass the data to external systems which can't handle UTC datetimes - You need to do calculations which depend on the timezone (the most common one is "what date is it now in timezone X?". So, timezone.now() returns the correct value. UTC-datetime is what you want in Python. There maybe could be a shortcut function for local- now. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: timezone.now() when USE_TZ=true
2012/6/1 Artem Andreev : > May be it will be more practical/comfortable for django users if > timezone.now() will return localetime? > What do you think about this? Hi Artem, In fact this problem isn't limited to timezone.now(): any datetime returned by the database will be expressed with tzinfo = UTC. All datetimes have to be converted when they're exchanged with another system that expects something other than UTC. In your situation, you are supposed to adapt your serialization function to convert datetimes according to your needs. Some APIs may expect UTC, others may expect naive local time, others may expect local time with a stated offset, etc. So there's no choice (UTC, default TZ, current TZ) will satisfy everyone. That's why I chose to stick with the sanest and least controversial choice: UTC. Arithmetic works without surprises and performance isn't hindered by conversions. Best regards, -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Django's CVB - Roadmap?
Hi, I was reading the blog post from Luke Plant recently on his views on Django's CBVs: http://lukeplant.me.uk/blog/posts/djangos-cbvs-were-a-mistake/ As well as the reply here: http://www.boredomandlaziness.org/2012/05/djangos-cbvs-are-not-mistake-but.html The reason for my post - is there anything from the Django core as a whole on this? What's the future roadmap like in terms of CBV's? Are there going to be any changes to it, or are we safe to assume things will be as they are now. I noticed that the documentation for CBV's is still a bit...bare? Is there any movement on the documentation or examples front? Cheers, Victor -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/kiJ0O3DljZQJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django's CVB - Roadmap?
On Fri, Jun 1, 2012 at 10:14 AM, Victor Hooi wrote: > The reason for my post - is there anything from the Django core as a whole > on this? What's the future roadmap like in terms of CBV's? Are there going > to be any changes to it, or are we safe to assume things will be as they are > now. I think as a whole we're divided. Luke's opinions differ from mine, and it's entirely unclear to me who's "right" or even if there's a "right" to be had. And that's just the two of us! I think this might be a situation where we need some more feedback from the community and some more time to decide what the right move here is. So... what do *you* think? Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django's CVB - Roadmap?
I tend to agree, in general, with the reply that there should be a function based api to cover the 80% use case, but in the case of Django's CBV's this is likely covered by the as_view method. On Friday, June 1, 2012 at 10:54 AM, Jacob Kaplan-Moss wrote: > On Fri, Jun 1, 2012 at 10:14 AM, Victor Hooi (mailto:victorh...@gmail.com)> wrote: > > The reason for my post - is there anything from the Django core as a whole > > on this? What's the future roadmap like in terms of CBV's? Are there going > > to be any changes to it, or are we safe to assume things will be as they are > > now. > > > > > I think as a whole we're divided. Luke's opinions differ from > mine, and it's entirely unclear to me who's "right" or even if there's > a "right" to be had. And that's just the two of us! > > I think this might be a situation where we need some more feedback > from the community and some more time to decide what the right move > here is. > > So... what do *you* think? > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django's CVB - Roadmap?
I am not ready to judge right now wether they are a good idea or not. I can completely agree that documentation makes the views more difficult then they actually are. Every time I create a new view, I find myself going to the source. I think this is a case where the learning curve initially is a little steeper so better examples and best-practices will really help with people's implementation and also this discussion. I have been wanting to write up documentation every time I go to the source, but sadly haven't had the time. Maybe I will soon. On Fri, Jun 1, 2012 at 12:35 PM, Donald Stufft wrote: > I tend to agree, in general, with the reply that there should be a > function based api > to cover the 80% use case, but in the case of Django's CBV's this is likely > covered by the as_view method. > > On Friday, June 1, 2012 at 10:54 AM, Jacob Kaplan-Moss wrote: > > On Fri, Jun 1, 2012 at 10:14 AM, Victor Hooi wrote: > > The reason for my post - is there anything from the Django core as a whole > on this? What's the future roadmap like in terms of CBV's? Are there going > to be any changes to it, or are we safe to assume things will be as they > are > now. > > > I think as a whole we're divided. Luke's opinions differ from > mine, and it's entirely unclear to me who's "right" or even if there's > a "right" to be had. And that's just the two of us! > > I think this might be a situation where we need some more feedback > from the community and some more time to decide what the right move > here is. > > So... what do *you* think? > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django's CVB - Roadmap?
On Fri, Jun 1, 2012 at 12:04 PM, Michael wrote: > I am not ready to judge right now wether they are a good idea or not. > > I can completely agree that documentation makes the views more difficult > then they actually are. Every time I create a new view, I find myself going > to the source. I think this is a case where the learning curve initially is > a little steeper so better examples and best-practices will really help > with people's implementation and also this discussion. > > This is the real issue. The docs. I'm trying to use CBVs exclusively in my latest project. I end up in the source most of the time. It might be good to start people out with very basic CBVs and make the docs much more of a tutorial. > I have been wanting to write up documentation every time I go to the > source, but sadly haven't had the time. Maybe I will soon. > > > > > > On Fri, Jun 1, 2012 at 12:35 PM, Donald Stufft wrote: > >> I tend to agree, in general, with the reply that there should be a >> function based api >> to cover the 80% use case, but in the case of Django's CBV's this is >> likely >> covered by the as_view method. >> >> On Friday, June 1, 2012 at 10:54 AM, Jacob Kaplan-Moss wrote: >> >> On Fri, Jun 1, 2012 at 10:14 AM, Victor Hooi >> wrote: >> >> The reason for my post - is there anything from the Django core as a whole >> on this? What's the future roadmap like in terms of CBV's? Are there going >> to be any changes to it, or are we safe to assume things will be as they >> are >> now. >> >> >> I think as a whole we're divided. Luke's opinions differ from >> mine, and it's entirely unclear to me who's "right" or even if there's >> a "right" to be had. And that's just the two of us! >> >> I think this might be a situation where we need some more feedback >> from the community and some more time to decide what the right move >> here is. >> >> So... what do *you* think? >> >> Jacob >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to django-developers@googlegroups.com. >> To unsubscribe from this group, send email to >> django-developers+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to django-developers@googlegroups.com. >> To unsubscribe from this group, send email to >> django-developers+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
admin_changelist failing on Oracle
I'm getting an error when syncdb tries to execute the following SQL against Oracle 10g XE: CREATE OR REPLACE TRIGGER "ADMIN_CHANGELIST_EVENT_TR" BEFORE INSERT ON "ADMIN_CHANGELIST_EVENT" FOR EACH ROW WHEN (new."ID" IS NULL) BEGIN SELECT "ADMIN_CHANGELIST_EVENT_SQ".nextval INTO :new."ID" FROM dual; END; The error is django.db.utils.DatabaseError: ORA-06552: PL/SQL: Compilation unit analysis terminated ORA-06553: PLS-320: the declaration of the type of this expression is incomplete or malformed Can anyone suggest what the problem is? Regards, Vinay Sajip -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django's CVB - Roadmap?
The docs around the provided CBVs and mixins are an issue, but also what is missing is that programmers seem to still think those that are provided should work for more cases than they probably do. When the narrative for CBVs is documented, should Django focus on mixins and state the expected limits of the provided classes? I think people are finding those limits pretty quickly (e.g., "I need more than one form on this page!"), and then perhaps conclude that CBV's are "broken". Perhaps the idea that your site or Django app may need more specific base-classes needs more promotion? -- Steven On Fri, Jun 1, 2012 at 12:21 PM, Adam "Cezar" Jenkins < emperorce...@gmail.com> wrote: > On Fri, Jun 1, 2012 at 12:04 PM, Michael wrote: > >> I am not ready to judge right now wether they are a good idea or not. >> >> I can completely agree that documentation makes the views more difficult >> then they actually are. Every time I create a new view, I find myself going >> to the source. I think this is a case where the learning curve initially is >> a little steeper so better examples and best-practices will really help >> with people's implementation and also this discussion. >> >> > This is the real issue. The docs. I'm trying to use CBVs exclusively in my > latest project. I end up in the source most of the time. It might be good > to start people out with very basic CBVs and make the docs much more of a > tutorial. > > > >> I have been wanting to write up documentation every time I go to the >> source, but sadly haven't had the time. Maybe I will soon. >> >> >> >> >> >> On Fri, Jun 1, 2012 at 12:35 PM, Donald Stufft >> wrote: >> >>> I tend to agree, in general, with the reply that there should be a >>> function based api >>> to cover the 80% use case, but in the case of Django's CBV's this is >>> likely >>> covered by the as_view method. >>> >>> On Friday, June 1, 2012 at 10:54 AM, Jacob Kaplan-Moss wrote: >>> >>> On Fri, Jun 1, 2012 at 10:14 AM, Victor Hooi >>> wrote: >>> >>> The reason for my post - is there anything from the Django core as a >>> whole >>> on this? What's the future roadmap like in terms of CBV's? Are there >>> going >>> to be any changes to it, or are we safe to assume things will be as they >>> are >>> now. >>> >>> >>> I think as a whole we're divided. Luke's opinions differ from >>> mine, and it's entirely unclear to me who's "right" or even if there's >>> a "right" to be had. And that's just the two of us! >>> >>> I think this might be a situation where we need some more feedback >>> from the community and some more time to decide what the right move >>> here is. >>> >>> So... what do *you* think? >>> >>> Jacob >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers" group. >>> To post to this group, send email to django-developers@googlegroups.com. >>> To unsubscribe from this group, send email to >>> django-developers+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/django-developers?hl=en. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers" group. >>> To post to this group, send email to django-developers@googlegroups.com. >>> To unsubscribe from this group, send email to >>> django-developers+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/django-developers?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to django-developers@googlegroups.com. >> To unsubscribe from this group, send email to >> django-developers+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: admin_changelist failing on Oracle
On Fri, Jun 1, 2012 at 11:29 AM, Vinay Sajip wrote: > I'm getting an error when syncdb tries to execute the following SQL > against Oracle 10g XE: > > CREATE OR REPLACE TRIGGER "ADMIN_CHANGELIST_EVENT_TR" > BEFORE INSERT ON "ADMIN_CHANGELIST_EVENT" > FOR EACH ROW > WHEN (new."ID" IS NULL) > BEGIN > SELECT "ADMIN_CHANGELIST_EVENT_SQ".nextval > INTO :new."ID" FROM dual; > END; > > The error is > > django.db.utils.DatabaseError: ORA-06552: PL/SQL: Compilation unit > analysis terminated > ORA-06553: PLS-320: the declaration of the type of this expression is > incomplete or malformed > > Can anyone suggest what the problem is? The error is caused by one of the column names in the table. See the second paragraph at: https://docs.djangoproject.com/en/1.4/ref/databases/#naming-issues It's a frustrating error because the column name is perfectly valid, and it has no problem creating the table; it just causes an arbitrary-looking error when you try to create the trigger. Cheers, Ian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Non-default managers in related field lookups
On Fri, Jun 1, 2012 at 2:26 AM, Russell Keith-Magee
wrote:
> On Fri, Jun 1, 2012 at 8:53 AM, Jeremy Dunck wrote:
...
>> Candidate.context('site') would return a manager depending on the
>> requested context.
>> (or perhaps Candidate.objects.using(context='site')... or
>> Candidate.objects.context('site'))
>>
>> # get an instance while assigning ._state.context == 'site', similar
>> to ._state.db
>> candidate_with_unpublished_races = Candidate.context('site')
...
> Is this really something that's going to be able to be managed at the
> routing level? It seems to me that the decision about exactly which
> set of objects you want returned needs much finer control that a
> router method will allow.
>
...
> Here's a counter-proposal:
>
...
> * race.candidates.all() would use _default_manager
>
> * race.candidates('objects_all').all() would use the objects_all manager
>
> * race.candidates('objects').all() would also use _default_manager
> (but explicitly)
OK, the problem I'm trying to address is "stickiness" of purpose.
Unless we have well-known names, the admin app couldn't know to use
Main.related_name(context_name).all on its inline lookups.
The thought was that
class EventAdmin(Admin):
def queryset(self):
return self.model.objects('admin')
would result in an event instance whose person_set descriptor would
continue returning objects as useful for admin, without needing to
know to call event.person_set('admin') and so on. I think well-known
names would lead to composability problems between apps.
I felt that putting it in the router nicely paralleled db_for_read in
the sense that the instance.save method writes to the ._state.db from
which the instance was received, or asks db_for_write if no such DB is
known. This continues the idea of db aliases, where the alias name is
abstract and the behavior of that name is centralized into the router.
In your objection, yes, I'm saying that a race gotten through
Race.objects.context('admin') (or Race.object('admin') if you prefer
to spell it that way) would have a .candidates which returns for the
'admin' context, whatever that means, unless told otherwise. The
implicit contract right now is that it returns 'default'.If you
wanted candidates outside of the 'admin' subset, you probably didn't
want to get a race through that context.
In any case, I understand your concern that the router approach might
not be flexible enough for general purposes, but I have a specific
purpose of needing "sticky" behavior in related lookups in a similar
manner to ._state.db does currently.
If you can see what I'm driving at, can you see a way to integrate
addressing the "sticky" need with your approach?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: admin_changelist failing on Oracle
On Jun 1, 6:39 pm, Ian Kelly wrote: > > The error is caused by one of the column names in the table. See the > second paragraph at: > > https://docs.djangoproject.com/en/1.4/ref/databases/#naming-issues > Thanks, that helped. It seems that in this case, the offending name is 'date'. I added a db_column='event_date' and all seems well. As this is a standard Django regression test, I presume a ticket should be raised? Regards, Vinay Sajip -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: timezone.now() when USE_TZ=true
Anssi, Aymeric thanks! I enabled USE_TZ only 3 days ago and missed that any datetime returned by the database is expressed with tzinfo = UTC. Until that moment I though that function localtimezone.now() that will return localtime(timezone.now()) solves most of my problems. Now I want to turn off USE_TZ :) Joking apart but seems as a lot of systems expect datetime naive. Also I have a lot of ajax responses. Thus I should converts a lot of manually, which increases the possibility of error. Maybe this is just my experience. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/SuWCI-IEX5kJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django's CVB - Roadmap?
Hi there, IMHO I think we are discussing two different topics here. The first one is documentation. I've just added a page to the wiki outlining the actual state of the CVB docs and some ideas on how we can improve it. Please fell free to expand/object/modify/destroy what I've written. I hope that between us all we can decide which way to move forward regarding the documentation in an organized effort. At least agree as a community in how to organize the docs, so we could then have "pieces" of docs outlined to be written. You can check it out here: https://code.djangoproject.com/wiki/ClassBasedViewsDocs The second one is the actual Generic CBV. From my point of view there's a missing GCBV which I've discussed in https://groups.google.com/d/msg/django-developers/rkh9oG603XI/By78sCl3xmsJ . Right now I'm thinking about a different approach that I've been discussing in #django-dev. A view that can handle any number of "formlike objects" (eg modelforms, formsets, inline formsets), validate and process them. This is a common problem that most projects would be able to use. Hope that with all this movement we can move this aspect of Django forward. Regards, Iván On Fri, Jun 1, 2012 at 2:36 PM, Steven Cummings wrote: > The docs around the provided CBVs and mixins are an issue, but also what is > missing is that programmers seem to still think those that are provided > should work for more cases than they probably do. When the narrative for > CBVs is documented, should Django focus on mixins and state the expected > limits of the provided classes? I think people are finding those limits > pretty quickly (e.g., "I need more than one form on this page!"), and then > perhaps conclude that CBV's are "broken". Perhaps the idea that your site or > Django app may need more specific base-classes needs more promotion? > > -- > Steven > > > > On Fri, Jun 1, 2012 at 12:21 PM, Adam "Cezar" Jenkins > wrote: >> >> On Fri, Jun 1, 2012 at 12:04 PM, Michael wrote: >>> >>> I am not ready to judge right now wether they are a good idea or not. >>> >>> I can completely agree that documentation makes the views more difficult >>> then they actually are. Every time I create a new view, I find myself going >>> to the source. I think this is a case where the learning curve initially is >>> a little steeper so better examples and best-practices will really help with >>> people's implementation and also this discussion. >>> >> >> This is the real issue. The docs. I'm trying to use CBVs exclusively in my >> latest project. I end up in the source most of the time. It might be good to >> start people out with very basic CBVs and make the docs much more of a >> tutorial. >> >> >>> >>> I have been wanting to write up documentation every time I go to the >>> source, but sadly haven't had the time. Maybe I will soon. >>> >>> >>> >>> >>> >>> On Fri, Jun 1, 2012 at 12:35 PM, Donald Stufft >>> wrote: I tend to agree, in general, with the reply that there should be a function based api to cover the 80% use case, but in the case of Django's CBV's this is likely covered by the as_view method. On Friday, June 1, 2012 at 10:54 AM, Jacob Kaplan-Moss wrote: On Fri, Jun 1, 2012 at 10:14 AM, Victor Hooi wrote: The reason for my post - is there anything from the Django core as a whole on this? What's the future roadmap like in terms of CBV's? Are there going to be any changes to it, or are we safe to assume things will be as they are now. I think as a whole we're divided. Luke's opinions differ from mine, and it's entirely unclear to me who's "right" or even if there's a "right" to be had. And that's just the two of us! I think this might be a situation where we need some more feedback from the community and some more time to decide what the right move here is. So... what do *you* think? Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Django developers" group. >>> To post to this group, send email to django-developers@googl
Re: timezone.now() when USE_TZ=true
On 1 juin 2012, at 20:56, Artem Andreev wrote: > seems as a lot of systems expect datetime naive Yes, that's unfortunate. All hope is not lost. 10 years ago, lots of systems expected ASCII and choked on UTF-8; some have improved since then. > I should converts a lot of manually, which increases the possibility of > error. Maybe this is just my experience. You should be able to control this problem with a function or class that handles all you AJAX responses. When you say "AJAX", I suppose you're returning JSON. This function would walk through the datastructure, find datetimes, and convert them to local time, before serializing in JSON. Best regards, -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: admin_changelist failing on Oracle
On Fri, Jun 1, 2012 at 12:29 PM, Vinay Sajip wrote: > > On Jun 1, 6:39 pm, Ian Kelly wrote: >> >> The error is caused by one of the column names in the table. See the >> second paragraph at: >> >> https://docs.djangoproject.com/en/1.4/ref/databases/#naming-issues >> > > Thanks, that helped. It seems that in this case, the offending name is > 'date'. I added a db_column='event_date' and all seems well. As this > is a standard Django regression test, I presume a ticket should be > raised? I don't think a whole ticket should be needed for this, just a pull request. It's the kind of thing that I would have just committed without a ticket back when we were using subversion. I'm a bit out of touch with process these days, though, so I could be wrong. Cheers, Ian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django's CVB - Roadmap?
On Fri, Jun 1, 2012 at 3:45 PM, Iván Raskovsky wrote: > Hi there, IMHO I think we are discussing two different topics here. > > The first one is documentation... > > The second one is the actual Generic CBV... There's a third complaint that several people have mentioned that is deeper than both these problems. This is that CBVs mask control flow and this makes them inherently harder to use. Basically, since the order of execution of your methods is an implementation detail of the base class, everyone needs to refer to the documentation whenever they try to examine a CBV. This is somewhat related to the Generic CBV problem, in that a lot of the people who ask "Why can't I do X with a Generic CBV" are really asking, "Why isn't there a place to put what I need into the control flow" and the answer is "Because when flow is inverted, every extensibility point must be explicit." Adding more extensibility points like multiple forms does nothing to fundamentally change this, it just changes Generic CBVs from the 80% solution to the 90% solution to the 95% solution, etc. They will never be a 100% solution, precisely because control flow is inverted. This problem is a really deep one, and has parallels with other long-term sticking points in Django, such as the app model. Apps provide a whole bunch of piecemeal functionality: some views, some templates, some models, some tests, some urls, and these are all executed and/or processed by Django based on its particular implementation. For example, instead of reading the template from the filesystem, you call a Django library function that reaches into its global collection of loaded templates and retrieves it for you. In CBVs, instead of calling validate() on some form, you rely on the internals executing something for you, which makes understanding preconditions for various methods difficult to understand without extensive docs. Anyways, this is a deeper problem than "There are two things we can fix, let's get on that." Best, Alex Ogier -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: admin_changelist failing on Oracle
On Sat, Jun 2, 2012 at 5:39 AM, Ian Kelly wrote: > On Fri, Jun 1, 2012 at 12:29 PM, Vinay Sajip wrote: >> >> On Jun 1, 6:39 pm, Ian Kelly wrote: >>> >>> The error is caused by one of the column names in the table. See the >>> second paragraph at: >>> >>> https://docs.djangoproject.com/en/1.4/ref/databases/#naming-issues >>> >> >> Thanks, that helped. It seems that in this case, the offending name is >> 'date'. I added a db_column='event_date' and all seems well. As this >> is a standard Django regression test, I presume a ticket should be >> raised? > > I don't think a whole ticket should be needed for this, just a pull > request. It's the kind of thing that I would have just committed > without a ticket back when we were using subversion. I'm a bit out of > touch with process these days, though, so I could be wrong. For auditing purposes, a ticket is always helpful, even if the ticket is closed straight away. That way, anyone who hits the same problem later on can see the source of the problem and the fact that a solution should be coming in the near future. It would also be nice to be able to catch these problems as an automated validation process… but that's a much bigger issue. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Non-default managers in related field lookups
On Fri, Jun 1, 2012 at 7:28 PM, Sebastian Goll wrote:
> On Fri, 1 Jun 2012 17:26:54 +0800
> Russell Keith-Magee wrote:
>
>> Here's a counter-proposal: (…)
>>
>> So, using your example:
>>
>> * race.candidates.all() would use _default_manager
>>
>> * race.candidates('objects_all').all() would use the objects_all manager
>>
>> * race.candidates('objects').all() would also use _default_manager
>> (but explicitly)
>>
>> (…)
>>
>> For my money, that's an explicit API that makes sense when reading the
>> single query line, and doesn't require the interpolation of extra
>> state/context from a router or some other context manager. It's also
>> backwards compatible, because there won't be any existing code
>> invoking __call__() on a manager.
>
> FWIW, something very similar has been implemented in ticket #3871 [1],
> patch `r17204-custom-reverse-managers.diff` [2], minus the __call__
> notation. The patch in the ticket uses an explicit method named
> `manager`, however using __call__ seems more elegant (+ 1).
>
> Maybe the efforts from that patch can be revisited.
Thanks for finding that ticket, Sebastian -- this is an old debate, so
it doesn't surprise me that there is an old ticket covering the issue.
(I also find it comforting that the ticket history reveals I'm mostly
consistent in my opinions… :-)
If we can leverage some/all of the code from that patch, then we
absolutely should.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Non-default managers in related field lookups
On Fri, Jun 1, 2012 at 7:08 PM, Anssi Kääriäinen
wrote:
> On Jun 1, 1:43 pm, Russell Keith-Magee
> wrote:
>> > Just as a bike-shedding thought: Would it be possible to have
>> > frank.events.confirmed.all() as the syntax? I see this a tiny bit
>> > cleaner. On the other hand it isn't explicit you can only use
>> > the .confirmed only directly after the events, and there is the
>> > possibility of clashing with queryset methods. The clash issue can be
>> > solved by just using frank.events('clashing_name').all() instead of
>> > frank.events.clashing_name.all() in the rare cases this is needed.
>>
>> True - but providing an API that avoids the clash in the first place
>> is preferable, IMHO.
>>
>> That said, I'm not *strongly* opposed to .events.confirmed -- it just
>> tastes a bit funny. I'd rather not eat it, but if if everyone else
>> says I should…. :-)
>
> As said, just bike-shedding. Lets go with the call-notation for now.
> It is easy enough to bike-shed this more later. The call syntax is
> clear enough, and it is explicit and should be easy to make that work.
>
>> > How would this work with prefetch_related? Maybe
>> > prefetch_related('events__confirmed')? IMHO this is an important use
>> > case, as there isn't currently any possibility to use different
>> > filtering, ordering etc than the one given by the default related
>> > manager.
>>
>> That's a good point -- I hadn't thought of the consequences on
>> prefetch_related. I'm not wild about overloading the __ notation to
>> add the 'manager selector" interpretation. There are already
>> complications differentiating between aggregates, filter clauses,
>> related fields… I don't think we need to add another to this mix.
>>
>> How about a kwarg to prefetch_related? For example:
>>
>> person.prefetch_related('events', managers={'events': 'confirmed'})
>>
>> or maybe just use kwargs directly:
>>
>> person.prefetch_related(events='confirmed')
>>
>> If you start getting into multiple joins, it's going to get more
>> complex; we might have to require a list of managers:
>>
>> person.prefetch_related(events__things=['confirmed', 'objects'])
>
> This API has one problem: what if you want confirmed events in one
> list, and then non-confirmed events in another?
>
> I created a ticket where you could use R-objects for prefetch related.
> The idea is that you can use any query you like, and fetch the related
> objects to any attribute you like.
>
> In short, the API is this:
> SomeModel.objects.prefetch_related(
> R('events', to_attr='confirmed_events',
> qs=RelModel.confirmed.order_by('foo')),
> )
>
> You can chain those calls:
> Person.objects.prefetch_related(
> R('events', to_attr='confirmed_events',
> qs=Event.confirmed.order_by('foo')),
> R('confirmed_events__locations', to_attr='locations',
> qs=Location.objects.order_by('name')),
> )
> Every Person object fetched fill have a list "confirmed_events", and
> each confirmed event will have an attribute "locations".
I might be missing something in the details here, but are you
proposing here that even though there's only one FK reverse relation
from Event to Person, there would be 2 attributes (events and
confirmed_events) containing lists? That doesn't strike me as a good
idea in itself -- or, at least, something that needs to be followed
through elsewhere in the API. Introducing attributes to a model as a
result of a prefetch_related call isn't something that has an analog
anywhere else in the ORM, AFAICT.
If you drop the 'multiple attributes' thing, then the general problem
you describe could be syntactically covered by:
Person.objects.prefetch_related('events',
events__locations=['confirmed','objects'])
i.e., the events attribute is prefetch-populated with the default
manager, but only those matching the confirmed manager would have a
location pre-poulated. However, this would be a can of worms all of
its own as far as implementation is concerned (probably not
impossible, but sufficiently complex to implement and maintain that I
would be completely comfortable saying "no, you can't do that").
And that's something I'm willing to do more broadly, too.
Prefetch_related is an optimisation. If we can find an elegant way to
integrate non-default manager selection, then sure -- lets do it. But
if we can only introduce non-default manager selection at the cost of
a hideously complex API, then I'm inclined to just call it a
limitation (albeit an unfortunate one) of the feature.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Non-default managers in related field lookups
On Sat, Jun 2, 2012 at 1:54 AM, Jeremy Dunck wrote:
> On Fri, Jun 1, 2012 at 2:26 AM, Russell Keith-Magee
> wrote:
>> On Fri, Jun 1, 2012 at 8:53 AM, Jeremy Dunck wrote:
> ...
>>> Candidate.context('site') would return a manager depending on the
>>> requested context.
>>> (or perhaps Candidate.objects.using(context='site')... or
>>> Candidate.objects.context('site'))
>>>
>>> # get an instance while assigning ._state.context == 'site', similar
>>> to ._state.db
>>> candidate_with_unpublished_races = Candidate.context('site')
> ...
>> Is this really something that's going to be able to be managed at the
>> routing level? It seems to me that the decision about exactly which
>> set of objects you want returned needs much finer control that a
>> router method will allow.
>>
> ...
>> Here's a counter-proposal:
>>
> ...
>> * race.candidates.all() would use _default_manager
>>
>> * race.candidates('objects_all').all() would use the objects_all manager
>>
>> * race.candidates('objects').all() would also use _default_manager
>> (but explicitly)
>
>
> OK, the problem I'm trying to address is "stickiness" of purpose.
> Unless we have well-known names, the admin app couldn't know to use
> Main.related_name(context_name).all on its inline lookups.
> The thought was that
>
> class EventAdmin(Admin):
> def queryset(self):
> return self.model.objects('admin')
>
> would result in an event instance whose person_set descriptor would
> continue returning objects as useful for admin, without needing to
> know to call event.person_set('admin') and so on. I think well-known
> names would lead to composability problems between apps.
>
> I felt that putting it in the router nicely paralleled db_for_read in
> the sense that the instance.save method writes to the ._state.db from
> which the instance was received, or asks db_for_write if no such DB is
> known. This continues the idea of db aliases, where the alias name is
> abstract and the behavior of that name is centralized into the router.
>
> In your objection, yes, I'm saying that a race gotten through
> Race.objects.context('admin') (or Race.object('admin') if you prefer
> to spell it that way) would have a .candidates which returns for the
> 'admin' context, whatever that means, unless told otherwise. The
> implicit contract right now is that it returns 'default'. If you
> wanted candidates outside of the 'admin' subset, you probably didn't
> want to get a race through that context.
>
> In any case, I understand your concern that the router approach might
> not be flexible enough for general purposes, but I have a specific
> purpose of needing "sticky" behavior in related lookups in a similar
> manner to ._state.db does currently.
True. I suppose the question here is whether the use case you're
describing -- "In site context A return subset X" -- is a general
usage pattern with a general implementation pattern, or something that
only exists in your specific use case; and if it's a general use
pattern, is it something that can/should be handled with a
routing-style behaviour, or by a slightly more abstract 'explicit'
handling.
However, here's my problem. Lets take database selection as an analogy:
The DB router doesn't *require* any manual selection of databases. The
model class and instance provides all the details required for most
routing decisions. You can manually force database selection (with
using()), and database selection will cascade down joins. However,
manual database selection isn't done by alias -- you don't say "select
the 'write' database", you specifically name the database that is used
for writes -- ok, you use an alias, but the alias is an alias for the
specific database connection, not for the broader behaviour that the
connection is performing.
In the manager selection case, the model class and instance doesn't
provide enough details for the routing decision -- the fact that
you're "in the admin" is a broader concept. So you need provide the
context in code. However, this means that one of three approaches is
needed:
Firstly, you write methods that are specifically "admin" methods,
rather than general utilities. This seems to defeat the purpose of
abstracting the manager selection process -- you might as well be
explicit about manager selection in this case.
Secondly, you write methods that take a "context" as an argument. This
might work fine under some circumstances, but for this sort of thing
to work in the admin, we'd need to ensure that every admin extension
point takes a new 'context' argument -- which seems extremely invasive
to me.
Thirdly, you write methods that take a "pre-contextualized" object as
an argument. This fits slightly better with the admin case (we can
make the origin query set set a context, and that then cascades down).
The third approach is the most appetising from an architectural point
of view, but -- and here's my problem -- I'm not convinced it's
something where there is a 'generic' behavior that war
Re: timezone.now() when USE_TZ=true
суббота, 2 июня 2012 г., 1:05:01 UTC+4 пользователь Aymeric Augustin написал: > > On 1 juin 2012, at 20:56, Artem Andreev wrote: > > I should converts a lot of manually, which increases the possibility of > error. Maybe this is just my experience. > > You should be able to control this problem with a function or class that > handles all you AJAX responses. When you say "AJAX", I suppose you're > returning JSON. This function would walk through the datastructure, find > datetimes, and convert them to local time, before serializing in JSON. > Thanks, Aymeric. Of course, I can create something like function localize_datetimes and use it in JSONResponseMixin and all places where I send data to external systems. But such function, JSONResponseMixin, etc should implement all django users who works with AJAX and external systems that expects datetime naive. Other solution - if database layer and timezone.now() will return datetimes with active timezone. IMHO such solution more friendly to django users. I understand that I am a little late to this discussion. And such cases can affect not so much django users. Perhaps it would be better to wait a feedback from other users. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/rEEsepqSq1kJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
