Wednesday, October 17, 2018¶
Loading from a python dump¶
Hamza, why did you set loading_from_dump to True in
install_migrations? Your
code change caused failures in all demo projects with a
RestoreTestCase. I
undid your change because I am afraid it might cause problems when
restoring a dump of a production site.
It seems that we need to document why loading_from_dump exists and what it does.
When loading a python fixture, the dpy loader loads calls
full_clean() and save() on every single row. That’s what
we want.
But then we have models whose full_clean or save method can decide to create other database objects.
For example the save() method of a user in welfare says:
def save(self, *args, **kwargs):
super(User, self). save(*args, **kwargs)
...
if self.calendar and not settings.SITE.loading_from_dump:
rt.models.cal.check_subscription(self, self.calendar)
In Lino Welfare we have one calendar for every user (at least for
every user who has permission to use the calendar). When saving a
user, Lino Welfare calls lino_xl.lib.cal.check_subscription() to
make sure that the user subscribes to its own calendar.
Of course such actions must not happen when we are loading this row from a dump.
About demo bookings¶
I started to write end user documentation about how to manually clear matching partner movements.
A first problem for explaining is that the demo data is not really
optimal. About the demo_bookings fixtures.
lino_xl.lib.accounting
defines a list of “purchase stories” : each story represents a
provider who sends monthly invoices.