A more flexible one-to-many field; other plans
: Martin Holmes
Minutes: 120
The use of the Adaptive DB codebase seems to be increasing rather than the reverse, so I’ve refocused on it. Over the weekend, in response to a need in MAJW, I added something which will be generally useful in other projects, by making the one-to-many field sensitive to when it’s linking two records from the same table; in that case, it creates and manages two parallel records in the linking table, so that links appear in both linked records.
This reminded me that one annoyance I would like to fix is to discover a way that, when a record is saved and its table-row refreshed in the interface, it could also report any linked records that will also need to be updated, so that those table rows could (probably asyncronously) refresh themselves, keeping the tabular data view up to date. It is a little tricky to figure out which rows may have been changed by a one-to-many save operation, though. There’s also the issue of a field in a record having been changed when it is the display field for a foreign key link in another table. One could imagine a very leisurely process that would silently refresh all visible fields in all visible tables in the interface, but that could be a massive operation. Since it’s GUI stuff, it couldn’t be done by a webworker. Needs some serious thought.