Hi folks --
So obviously I didn't finish my documentation refactoring before
leaving for vacation. I'm slowing plinking away on it in various air-
and seaports, bus and train depots, but I'll not be able to wrap stuff
up until I get back mid-May.
Don't let my absence stop doc work, though! Since
I'd vote for create() and update() methods which seem the least
confusing, but that doesn't seem very popular. If it has to be done
with arguments on save(), I'd say force_create=False,
force_update=False is the easiest to read and understand.
I'd prefer either of those options over a null/true/f
Hello,
I've been looking into the different use cases for aggregation and
came across one that I wasn't very sure what should be the expected
behaviour (regardless of the syntax used to express it)
If we do something like:
Buyer.objects.all().annotate('purchases__quantity__sum', 'age__max')
or
> Purely in terms of OO design, because it's cleaner. Object
> composition is usually a more appropriate paradigm than class
> inheritance. To take the example from the post that started this
> thread, the relationship between users and user profiles is "has-a",
> not "is-a". So what would be t
I'm still not quite sure why we need any additional methods, or flags, or
anything. Can someone explain to me where the underlying API is having
issues?
On Thu, May 1, 2008 at 2:24 AM, Tai Lee <[EMAIL PROTECTED]> wrote:
>
> I'd vote for create() and update() methods which seem the least
> confusi
On Thu, May 1, 2008 at 10:31 AM, David Cramer <[EMAIL PROTECTED]> wrote:
> I'm still not quite sure why we need any additional methods, or flags, or
> anything. Can someone explain to me where the underlying API is having
> issues?
Malcolm's initial note creating this thread described an example
On Thu, May 1, 2008 at 10:49 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> On Thu, May 1, 2008 at 10:31 AM, David Cramer <[EMAIL PROTECTED]> wrote:
>
> > I'm still not quite sure why we need any additional methods, or flags, or
> anything. Can someone explain to me where the underlying API is havi
> Now that QSRF has landed, this type of thinking leads me to: who's
> working on 121-rewrite?
I'm fairly certain that in refactoring QuerySet, OneToOneField has
been fixed. It's the base mechanism that allows multi-table
subclassing to work, in fact.
--~--~-~--~~~-
On May 1, 2008, at 11:49 AM, [EMAIL PROTECTED] wrote:
>
>> Now that QSRF has landed, this type of thinking leads me to: who's
>> working on 121-rewrite?
>
> I'm fairly certain that in refactoring QuerySet, OneToOneField has
> been fixed. It's the base mechanism that allows multi-table
> subclas
It looks like someone else hit the same trivial bug I ran into and put
some considerable effort into writing a test case for it.
However, progress on getting this fix included seems to have stalled
over 3 months ago. Perhaps it was just never marked "Ready for
checkin"?
--~--~-~--~~-
Interesting problem. The real question is, what is the user's intent on a
query like that?
I have no idea. They probably are thinking along the lines of result #2 if
they don't understand the underlying SQL and #1 if they do. It's probably
not a good idea to assume either point of view. Using Sum
Hey, looks like you're making a ton of progress! If you could keep
this page up to date: http://code.djangoproject.com/wiki/DocSprint12Apr
if would be super helpful for people looking to help out, but not sure
what's left to be done.
On May 1, 3:32 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wro
Are you talking about cloning objects that exist in the database? To where
you'd pull it out, unset the ID and then resave it?
On Thu, May 1, 2008 at 8:01 AM, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> On Thu, May 1, 2008 at 10:49 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> > On Thu, May 1, 20
Hello,
The patch I am currently sustaining (http://code.djangoproject.com/
ticket/3163 - related to the capability of selective disabling of SQL
generation for some models on manage.py commands - i.e. making
possible to manually create the models matched to the SQL views, which
won't be bothered
can this be considered as difference of complex apply against 2
consequent applications of annotate?
like 2 filter applied one-by-one can be different from one complex filter?
like: .annotate('purchases__quantity__sum').annotate('age__max')
and .annotate('purchases__quantity__sum', 'age__max')?
co
Any comment, especially on the transaction model?
Thanks
--~--~-~--~~~---~--~~
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 unsubsc
Jean-François wrote:
> Any comment, especially on the transaction model?
If you want considered opinions you would do well to wait longer than 51
minutes!
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
--~--~-
Steve Holden said the following:
> If you want considered opinions you would do well to wait longer than 51
> minutes!
You should check the date as well as the time; he sent the first email
*two days* before the second.
--
Collin Grady
BOFH excuse #244:
Your cat tried to eat the mouse.
--~-
Collin Grady wrote:
> Steve Holden said the following:
>
>> If you want considered opinions you would do well to wait longer than 51
>> minutes!
>>
>
> You should check the date as well as the time; he sent the first email
> *two days* before the second.
>
Steve, perhaps next year at
Don Spaulding II wrote:
>
>
> Collin Grady wrote:
>> Steve Holden said the following:
>>
>>> If you want considered opinions you would do well to wait longer than 51
>>> minutes!
>>>
>>
>> You should check the date as well as the time; he sent the first email
>> *two days* before the se
Steve Holden said the following:
> PS: Completely off-topic apart from the "Teach Me Google", can anyone
> tell me why Google Groups/Gmail isn't sending me my own messages?
AFAIK it just doesn't do that - I just set my client to copy my replies to
django-dev into my inbox so that they're thread
21 matches
Mail list logo
