20111210

Preparing release 1.3.0

Some last details solved:

• lino.modlib.links.models.LinksFromThis.column_names

• removed contacts.RoleType and contacts.Role and adapted demo and std fixtures

• Adapted lino.apps.dsbe.migrate.migrate_from_1_2_8()

• Note that lino.apps.dsbe.models.ContactPersons inherits lino.modlib.links.models.LinksFromThis just to override the label.

• Discovered that due to a bug in previous dpy versions there were some Upload records on Role and RoleType in the customer’s database.

• Added unit test case lino.apps.dsbe.tests.dsbe_demo_tests.test11() (Anrede Kontaktperson eines Vertrags beim Ausdruck)

New function lino.utils.mti.create_child()

During the preliminary tests of the database migration we discovered a subtle but serious problem which finally lead to an internal improvement in the dpy backup/restore mechanism.

Loading dpy fixtures failed because there were now more complex dependencies due to the structure changes around links.Link converted from contacts.Role.

When creating a Person, User, Company or JobProvider (i.e. the MTI children of Contact), Python fixtures generated by lino.utils.dpy.Serializer used the lino.utils.mti.insert_child() function. This required a lookup in Contact. This lookup wasn’t only useless, but it failed when it was about an object that hadn’t yet been saved. The dpy.Deserializer usually handles such errors due to not yet existing related objects by “deferring” them and try to save them in a second loop. But in this case the Exception ocurred already during the instantiation and thus wasn’t handled by the deserializer.

That’s why Python fixtures now use the new function lino.utils.mti.create_child() instead of lino.utils.mti.insert_child(). The new function is documented and tested in lino.test_apps.mti.models