Models created from querysets aren't constructed with constructor

[Ivan Sagalaev]

Hello everyone (and especially Malcolm :-) )

I've just hit a wall with a behavior that I find a bit strange. When a
model is instantiated from a queryset result it's not created with it's
own constructor but instead uses Model.from_sequence that does creates
an Empty() instance and then changes its __class__ to a Model.

So here are couple of thoughts:

- am I right that it's done for performance reason?
- I think it should be documented as a backwards incompatible change
since people do overload Model.__init__ (at least I did :-))
- what's the recommended way of doing things like settings some simple
attributes on a model instance instead of using constructor?

[Marty Alchin]

On Mon, Apr 28, 2008 at 4:03 PM, Ivan Sagalaev
<man...@softwaremaniacs.org> wrote:
> I've just hit a wall with a behavior that I find a bit strange. When a
> model is instantiated from a queryset result it's not created with it's
> own constructor but instead uses Model.from_sequence that does creates
> an Empty() instance and then changes its __class__ to a Model.

I'm glad I'm not the only one to have noticed this, but I thought it
was something on my end until your email prompted me to look at it
again. I'm pretty sure I remember the discussion that led to
from_sequence(), so I understand why it's there and everything, but I
do agree that we need to have some way to trigger __init__() in that
case.

For those of you keeping score at home, the bug639 test relies on the
__init__() functionality, and the fact that it's not failing in trunk
is really just a fluke, owing to the fact that the tearDown() method
of the test case doesn't actually save the object again after
retrieving it. Since it currently throws a DeprecationWarning in my
filestorage code, I updated it to use the new API, which saves by
default when you call p.image.delete(). This, then, fails miserably
because _savecount was never set. That caused me no end of confusion
trying to figure out what I did wrong, since it works on trunk. I can
use p.image.delete(save=False) and get around it for the bug639 case,
but I do think it merits some discussion.

-Gul

[Martin Diers]

I could be wrong, but I believe that this is because a Model is not
derived from the default __metaclass__, but is generated by a separate
class factory which overrides the default behavior.

[Ivan Sagalaev]

Martin Diers wrote:
> I could be wrong, but I believe that this is because a Model is not
> derived from the default __metaclass__, but is generated by a separate
> class factory which overrides the default behavior.

Yes, but my question is not how it's happening but what's the reason of it.

[Malcolm Tredinnick]

I forgot that people might be overriding __init__ like this. I need to
rethink it. Somebody brought it up on django-users and I've asked them
to file a ticket. We shouldn't break existing code like that.

(I'm going to revert the use of form_sequence() in a minute so that
existing code continues to work.)

Malcolm

--
The early bird may get the worm, but the second mouse gets the cheese.
http://www.pointy-stick.com/blog/

[Malcolm Tredinnick]

On Mon, 2008-04-28 at 15:30 -0500, Martin Diers wrote:
> I could be wrong, but I believe that this is because a Model is not
> derived from the default __metaclass__, but is generated by a separate
> class factory which overrides the default behavior.

No, that has nothing to do with it. It's because models are constructed
via a "fast path" using the Model.from_sequence() method in some cases.

Malcolm

--
The cost of feathers has risen; even down is up!
http://www.pointy-stick.com/blog/