On Sun, Apr 27, 2008 at 8:18 PM, Ken Arnold <[EMAIL PROTECTED]>
wrote:
> Possible fix: define more clearly whether Django thinks that the model
> is in the database or not. Currently that's (IIRC) based on whether
> the model has a primary key. But as Malcolm points out, a semantic
> primary key
On Apr 27, 8:58 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sun, 2008-04-27 at 17:52 -0700, [EMAIL PROTECTED] wrote:
> > I'd like to point out that in #2705, the patch creators have put the
> > API on the side of the get(), as for_update(), so that the decision
> > about whether the sav
Le 27 avr. 08 à 22:37, Marty Alchin a écrit :
>
> On Sun, Apr 27, 2008 at 10:17 PM, Grégoire Cachet
> <[EMAIL PROTECTED]> wrote:
>> Why could you not include a parameter in the Meta class, like
>> no_update = True ?
>> By default, this parameter would be False.
>
> The problem is, in Malcolm's ex
On Sun, Apr 27, 2008 at 10:17 PM, Grégoire Cachet
<[EMAIL PROTECTED]> wrote:
> Why could you not include a parameter in the Meta class, like
> no_update = True ?
> By default, this parameter would be False.
The problem is, in Malcolm's example of an employee database, you
might well sometimes
Hey!
I have also been thinking to the problem lately.
If you're doing it because it's related to your business logic for a
specific model, I would rather see this feature in the model definition.
Why could you not include a parameter in the Meta class, like
no_update = True ?
By default, th
On 27-Apr-08, at 8:34 AM, Malcolm Tredinnick wrote:
> I merged queryset-refactor into trunk just now. This was changeset
> r7477.
w000t - thanks and congratulations Malcolm, you rock
--
regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/code/
--~--~-~--~~-
On Sun, 2008-04-27 at 20:14 -0500, Adrian Holovaty wrote:
> On Sun, Apr 27, 2008 at 6:53 PM, Malcolm Tredinnick
> <[EMAIL PROTECTED]> wrote:
> > Sometimes when calling save(), we know (for business reasons) that it
> > must create a new object or raise an error. Similarly, in other cases,
> >
On Sun, Apr 27, 2008 at 6:53 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> Sometimes when calling save(), we know (for business reasons) that it
> must create a new object or raise an error. Similarly, in other cases,
> it either must update an existing object or raise an error.
So I don
On Sun, 2008-04-27 at 20:59 -0400, Marty Alchin wrote:
> I'm a bit on the other side of the situation here. To me, save() seems
> adequately ambiguous, either inserting or updating depending on the
> situation. As an alternative, I'd think having separate methods, like
> create() and update() wou
I'm a bit on the other side of the situation here. To me, save() seems
adequately ambiguous, either inserting or updating depending on the
situation. As an alternative, I'd think having separate methods, like
create() and update() would make things clearer still.
In addition to avoiding the whole
On Sun, 2008-04-27 at 17:52 -0700, [EMAIL PROTECTED] wrote:
> I'd like to point out that in #2705, the patch creators have put the
> API on the side of the get(), as for_update(), so that the decision
> about whether the save should update or create is saved as state on
> the model instances them
I'd like to point out that in #2705, the patch creators have put the
API on the side of the get(), as for_update(), so that the decision
about whether the save should update or create is saved as state on
the model instances themselves. I don't really like that syntax, but
it is probably worth no
The testing issue was something that I emphasized in my GSOC proposal
(which wasn't accepted). I may or may not work on it this summer, but
for anyone interested, the full proposal is available here:
https://www.dupontmanual.org/wikis/spectops//FrontPage/DjangoTestFramework
Part 2 might be of in
On Sun, Apr 27, 2008 at 7:53 PM, Malcolm Tredinnick <
[EMAIL PROTECTED]> wrote:
> [snipped problem description]
>
> (1) Model.save(must_create=None) where "must_create" is True (must
> create), False (must not create) or None (try an update; if that fails,
> insert).
>
>Pros: one parameter
On Sun, Apr 27, 2008 at 1:02 PM, Marcob <[EMAIL PROTECTED]> wrote:
> I found that after queryset-merge in newforms-admin date_hierarchy
> filter doesn't work anymore: years and month are repeated.
Thanks for reporting this, Marco. Turns out the bug was a few layers
deeper -- it was in the handl
On Sun, Apr 27, 2008 at 8:00 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> So use both. Put the example file field usage in model tests and the
> other stuff in regression tests.
Yeah, that was the plan, I just wanted to make sure it wasn't the
"wrong" thing to do. Thanks.
-Gul
--~--~--
On Sun, 2008-04-27 at 19:42 -0400, Marty Alchin wrote:
[...]
> Well, my concern now is the notion of separate tests for separate
> things. We have modeltests and regressiontests, and it seems (to me)
> like the file storage does a little of both.
This is a case of (probably unfortunate) historic
One of the minor cleanup items I've got on my list now that the query
stuff is mostly done is fixing model saving so that in the odd cases
where finer control is necessary, we have it.
Sometimes when calling save(), we know (for business reasons) that it
must create a new object or raise an error
On Sun, Apr 27, 2008 at 1:37 AM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
> - The database reset is only used by django.test.TestCase. If you are
> using raw unittest.TestCase or doctests, the database isn't flushed,
> and so they can run quite quickly.
This addresses the root of my ques
On Sun, Apr 27, 2008 at 1:02 PM, Marcob <[EMAIL PROTECTED]> wrote:
> I found that after queryset-merge in newforms-admin date_hierarchy
> filter doesn't work anymore: years and month are repeated.
For the record, this bug exists in trunk, also. I'm going to take a
look at it now...
Adrian
--
On 25 Apr., 21:40, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
>
> Not to get too much into this discussion, but I tend to be slow to
> understand design patterns and other paradigms. What then would be the
> appropriate way to handle an app that managed authors? I can see two
> possibilities:
>
> c
On Apr 27, 2008, at 12:02 PM, Marcob wrote:
>
> I found that after queryset-merge in newforms-admin date_hierarchy
> filter doesn't work anymore: years and month are repeated.
> To fix it I wrote this quick hack in django/contrib/admin/
> templatetags/
> admin_list.py:
Can you open a ticket in
Malcolm, thank you so much for all the work that you've done. It
benefits so many people! Hopefully you can see just how much your
hard work is really appreciated by all of the positive vibes in the
internet tubes right now :)
--~--~-~--~~~---~--~~
You received th
> That was my thinking exactly. I think the cognitive dissonance
> involved in height__avg='average_height' is much greater than that in
> ({'average_height': 'height__avg}). Sure, it's new ORM syntax but it's
> also a new ORM feature. Overloading the existing syntax to do
> something that's
I found that after queryset-merge in newforms-admin date_hierarchy
filter doesn't work anymore: years and month are repeated.
To fix it I wrote this quick hack in django/contrib/admin/templatetags/
admin_list.py:
Line 240:
-days = cl.query_set.filter(**{year_field: year_lookup,
month_
Malcolm,
Thank you so much for everything you do to help this project. Just
based on changeset dates and time I know that you have put in
countless hours to get this work done. It's much appreciated.
> Indeed! Congrats! Now we need to get brosner to throw this into NFA so
> us branchies can st
On Sun, Apr 27, 2008 at 1:51 PM, Trevor Caira <[EMAIL PROTECTED]> wrote:
>
> Would it be possible to, instead of manually specifying when to reset
> the database, automatically reset the database the first time that a
> test attempts to access it in a test case, and not reset again until
> the
On Sun, Apr 27, 2008 at 3:23 PM, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On Apr 27, 6:37 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> wrote:
>
> > - The slow operation is resetting the database. As far as I know,
> > there isn't much that can be done about this. No matter which way you
On Sun, 2008-04-27 at 15:19 +1000, Greg Turner wrote:
> We have postcode data for all of Australia, enabling the suburb and
> state/territory to be derived from a postcode. That's about 17,000
> records, so would best be stored in a database, not kept in memory as
> a localflavor.
>
> Data
On Sun, 2008-04-27 at 00:19 -0700, Simon Willison wrote:
[...]
> One of my favourite new features is the ability to more easily see the
> SQL that is going to be run against the database for a given queryset,
> using the new .query and .query.as_sql() methods:
>
> >>> print Woo.objects.filter(na
Indeed! Congrats! Now we need to get brosner to throw this into NFA so
us branchies can start playing with it as well. :)
On Apr 26, 11:30 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Massive congratulations and thanks all around, and to Malcolm!
>
> On Apr 27, 1:04 am, "Mike Scott" <[EMA
On Apr 27, 6:37 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> - The slow operation is resetting the database. As far as I know,
> there isn't much that can be done about this. No matter which way you
> do it, deleting a whole lot of data then re-establishing database
> structure is an exp
On Apr 27, 1:59 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> Its mostly there as a convenience for the really simple cases. There
> some duplication in typing annotate(avg_height=Avg('height'), so the
> shortcut is a convenience. IMHO, this is the sort of thing could be
> easily explaine
On Apr 27, 4:04 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> I merged queryset-refactor into trunk just now. This was changeset
> r7477.
Fantastic! Congratulations, and thank you.
One of my favourite new features is the ability to more easily see the
SQL that is going to be run against th
34 matches
Mail list logo
