Hi Arnold,
Am 15.11.2012 21:29, schrieb Arnold Krille:
Even if you do not need it outside the admin-interface (in this
project), from the logic this belongs to the model, not into some view.
Thank you very much for your replies, and in this regard (that the logic
would much better be kept in the model rather than elsewhere), I'm fully
with you.
However, I don't think that it works!
Please note that changing the 'begin' of a single period can imply
updates to several of them: the one before it in its old place (changed
'end' date), and the one before it in its new place (also changed 'end'
date).
So an implementation that updates all Periods of one staff member like
this seems to be reasonable:
end_date = date(2999, 12, 31) # or e.g. None
# Iterate the periods in *reverse* order:
for p in StaffMember.period_set.all().order_by('-begin'):
if p.end != end_date:
p.end = end_date
p.save()
end_date = p.begin
However, if this was moved into a save() override of Period, it would
introduce the problem of infinite recursion (this could be solved), but
it would *also* conflict with the save-loop in the admin interface,
please see the next paragraph:
Alas, if e.g. I overrode the save() method of the Period class, is it
safe to access *another* Period instance from there?
Yep, thats save.
If you use a db that has transactions, both the change to the other
object should be rolled back when saving of the current objects fails
as it should all end up in one transaction. :-)
I guess that when the admin interface saves a set of inlines, it has a
Queryset of them over which it loops and calls save(), e.g.
for p in InlinePeriodsQueryset:
p.save()
Now imagine that in the first iteration of this loop, p.save() calls or
has code like the update code above, where the *other* Periods of the
Staff member are updated, then enters the second iteration of this loop.
If my understanding is correct, this will overwrite a Period with
stale/outdated information, causing conflicts, won't it?
Thus my original question where to hook into the admin interface.
Despite your and my preference to have this generically work on the
level of model code, this seemingly simple updating of Period instances
seems best to be done *after* the admin interface has completed saving them.
So in fact, keeping these steps (admin saves all inlines, then update
them all as shown above) separate seems like a good idea to me, but I
still wonder where I should hook into the admin in order to call the
update code above?
Best regards,
Carsten
--
Cafu - the open-source Game and Graphics Engine
for multiplayer, cross-platform, real-time 3D Action
Learn more at http://www.cafu.de
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
