Thursday, June 27, 2019

Today I also pushed the changes described yesterday. See Wednesday, June 26, 2019.

Bleaching feature unveiled a name clash

The name “description” is used at different places, sometimes for real database fields, sometimes for virtual fields. In lino_xl.lib.topics.Topic this now caused a problem because the BleachChecker tries to get the value of the database field in order to bleach it, but gets the html.etree element returned by the virtual field.

We have a name clash. TIL that while it is okay to override a database field by a virtual field, the opposite is not true.

It happened actually only in lino_xl.lib.topics.Topic. To fix the problem, I renamed the database field description to description_text. This change requires a database migration. I’d have preferred to rename the virtual field in order to avoid database migrations, but this turned out rather non-trivial because the virtual field “description” is heavily being used in other places.

To avoid this pitfall in the future, Lino now checks for database fields hiding a virtual field defined on a parent and raises a ChangedAPI exception when this happens.

Nobody had noticed this until now because Django doesn’t know about Lino’s virtual fields. There is almost no problem when you define a database field which hides a previously defined virtual field of same name. The only problem is that when you try to get the value of the database field, Python will return the virtual field.

I wrote a demo project and a documentation page which tests it: Overriding virtual fields.

Other changes en passant:

The internal _bleached_fields attribute of lino.core.model.Model no longer contains the names but the field descriptors.

I changed the default value for textfield_bleached to True. Just to see what happens…

I optimized the reporting for data checkers. You can have 6 data checkers but 18 “checks”. One “check” is when a given checker is being run on a given model.

Suggesters

Auto-completion now works in react. But only when referring to tickets (after typing “#”) and not e.g. after a “@” to refer to a user. This behaviour that a “#” pops up a list of tickets is currently hard-coded in react.

Now I wrote my vision about how the app developer should configure this.