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

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 >>

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 >> >>

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

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: >> >>

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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 > > *

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

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,