On Mon, Apr 28, 2008 at 4:03 PM, Ivan Sagalaev <[EMAIL PROTECTED]> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
