Sorry if this has been mentioned but I couldn't find any reference to
it.
Anyway, there seems to be an issue with custom save() hooks and the
admin interface. When called from the shell .save() works as expected,
executing code both before and after the call to super(). However, in
the admin, i
wnielson wrote:
> Sorry if this has been mentioned but I couldn't find any reference to
> it.
>
> Anyway, there seems to be an issue with custom save() hooks and the
> admin interface. When called from the shell .save() works as expected,
> executing code both before and after the call to super(
Sorry for not posting an example, I was in a bit of a rush. Now that I
am at work I can afford a little longer explanation ;)
I have played with the problem more and have come to a conclusion that
it may be an issue with modifying ManyToMany relationships from the
admin interface through a custo
On 7/25/06, wnielson <[EMAIL PROTECTED]> wrote:
> if not self.genres.all():
> try:
>
> genre=Genre.objects.get(name='default') #default genre
> except:
>
Am 25.07.2006 um 22:41 schrieb James Bennett:
>
> On 7/25/06, wnielson <[EMAIL PROTECTED]> wrote:
>> if not self.genres.all():
>> try:
>> genre=Genre.objects.get
>> (name='default') #default g
On 7/25/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Wouldn't self.genres.all()[:1].count() save the database engine some
> work?
If you go that route, you don't need the count() anymore; slicing
forces the QuerySet to be evaluated.
Doing a SELECT COUNT(*) is pretty cheap, though, and DBs pr
On Jul 25, 2006, at 4:36 PM, James Bennett wrote:
> Doing a SELECT COUNT(*) is pretty cheap, though, and DBs probably have
> really good optimization for it, so I'd say it's a tossup as to which
> method is least stressful for the database.
Actually...
In most databases -- any that use MVCC --
On 7/25/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> In most databases -- any that use MVCC -- row counts are difficult to
> index, and thus COUNT(*) is usually O(N). MySQL is the big
> exception; it does index row counts and so COUNT(*) in MySQL is O(1).
Bah. Stil getting used to working
Still no go though. Even after removing the if not
self.genres.all().count(), it is still not updating the ManyToMany.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this grou
wnielson wrote:
> Still no go though. Even after removing the if not
> self.genres.all().count(), it is still not updating the ManyToMany.
I cannot believe this has got anything to do with the super call.
This is related to the many-to-many-relationship. I suggest that
you just try to add a genr
if I call save() on an object in the shell, it works perfectly;
--exactly as it should--. I will do some more digging today and try to
find out more.
btw, it looks like admin is using the model's default AddManipulator.
Would the fact that it is calling the AddManipulator instead of
directly cal
On Tue, 2006-07-25 at 16:36 -0500, James Bennett wrote:
[...]
> Ideally, just doing any sort of boolean test on a QuerySet would force
> it to evaluate; adding a __nonzero__ method to QuerySet would
> accomplish that, and the docs on when QuerySets are evaluated could be
> changed to reflect it.
>
On 7/26/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Assign it to me. I have the code written that just about makes this work
> already. So it will be a good reminder to finish it off.
Done (#2430).
While we're on the topic, the docs explicitly advise against doing
'len' on a QuerySet bec
James Bennett wrote:
> While we're on the topic, the docs explicitly advise against doing
> 'len' on a QuerySet because of the potential memory overhead of
> loading all the objects, and recommend using the QuerySet's 'count'
> method instead. Would it make more sense, then, to internally change
>
14 matches
Mail list logo
