Adaptive Database

The search fieldset can now be hidden or shown by the user by clicking on a triangle in the legend; and when a search is run, it's hidden automatically to make more space for the results.

I've got the new "choose which fields you see in the search results" feature working. It seems to be stable in the development site, and has no impact on the data entry features. It was a bit messy, and has resulted in a few lines of code being duplicated, so there are efficiency gains I could make with a bit of a re-factor, but overall it was less difficult than I feared. The feature can never realistically be extended to the custom fields -- it would be insanely complicated and painfully slow, for one thing, given that there are (at the last count) 110 custom fields. But I think JW might now consider consolidating some of those, and moving them back into the main table (something I could achieve on her instructions using SQL). Failing that, I think JW's project might be better served by its own customized, tuned search interface, to overcome some of the performance penalties that the generic AdaptiveDB backend code causes.

In preparation for adding a couple of new features, I've now ported back the changes I made in my personal songdb project, and then in the grsJournals project, to the dev site. Everything seems to be working. I'm now going to start working on making the fields to display selectable.

JW emailed to report a very odd thing with the db: all the values for the doc_to_docPeriods_id field in the documents table have been set to null except for nine. Trawling back through the backups, I discovered that on January 26, there were values in that field for most of the records. By February 1, they were all set to null.

This is impossible to achieve using the AdaptiveDB PHP interface, because that's a foreign key field, and the edit interface imposes a value on you when you edit it. So it can only have been achieved somehow by an administrator, maybe through PHPMyAdmin. The only scenario I can imagine is that someone deleted the docPeriods table; that would cause all those values to be set to null because it's a foreign key. Then if they restored the table (it's tiny -- only six records), the original field values would not be restored. Could that have happened? If so, who could have done it?

Using Transformer, I processed the Jan 26 dump to create update statements which re-insert the old values, and tested the results on my dev db. With JW's approval, I ran the script on the main db to reinsert the old values, and I've taken a fresh backup after doing that.

In all projects, add this:

div.tabCaptions{
[...]
  line-height: 200%;
}

Makes the tabs wrap properly when they won't fit on a line. Implemented in the Siberian project.