Replaced the integer Block field with a text field. I think we're done for now at least.
The old integer Plan field has now been replaced by a string field, with consequent updates to triggers and classes, and we now have a new Locations table to categorize the properties.
Working with SA, did some test encoding of a range of different directory entries, attempting to nail down our preferred encoding strategies ahead of developing the ODD file. We have dealt with most of the phenomena we expect to encounter. There's going to be a lot of heavy Schematron and content constraint going on to keep this nailed down, I think. It's an interesting mix between representation of the primary source (so we don't miss something that might later prove to be important) and database-style tagging (so everything taggable is tagged predictably and precisely)
Met with SA and the RAs from the directory cluster to discuss the range of different features we need to encode, and how we might do them. We have some good notes and basic ideas; the RAs will provide us with some screenshots of a range of different entry types, and we'll come up with a preliminary schema in the next few days.
More requests for change have come in from the field team, so we're discussing how best to do those before I start work on them. Must move cautiously with live data in the db.
JS-R requested more changes to the db -- basically splitting out lawyers from the owners table, which involves creating three new tables, migrating some data, and removing other data, so I've been writing and testing a script on the dev db. It appears to have worked OK, and the RAs will test on dev tomorrow while I go ahead and make the same changes on live. Then I'll have to update other scripts and of course the documentation. I really don't like working so close to the wire (they start entering data on Thursday) but there seems to be no help for it.
Finished the first pass through updates to database structure, including some quite gnarly triggers to auto-generate description fields. This is largely untested, but I have also created introductory documentation for the field workers and passed it on to them. In the process of testing today I once again encountered the dreaded caching problem that afflicts us with web content hosted through NFS mounts. I'm looking forward to getting this project shifted onto the project VM so we don't have this problem.
I've given RAs access to the dev db so they can play around without worrying about damaging real data.
Wrote and tested a bash script that does tarred gz backups with a daily, weekly, monthly and yearly staging system for the team Zotero db. Handy script to have around for all sorts of purposes, actually.
Working on the dev db, and recording all my structural changes in an SQL file I can run against live when I'm done, I've enhanced the owners table to add a useful auto-generated desc field maintained by triggers. Ditto with the title field. I've also separated out the name storage of institutional from human owners. All this has been a small education in how tricky it is to define triggers; I keep getting caught out by the delimiter thing. I still have to rework the props table, once we've decided on how best to describe properties; I think it'll have to be a listing of all the possible identifiers that might apply, along with making the desc field use an elegantly-constructed combination of them. But we don't yet know what might apply, so at the beginning I may have to err on the side of more identifier fields than we end up needing.
Had a good meeting with JS-R, the RAs, and JM (by Skype) to plan next week's initial work for them in the LTO.
Very helpful meeting at the Land Title Office where we learned about how titles are created, how parcels of land are created and described, and lots more. This causes us to re-think how we want the database to work, so it looks like we'll be redesigning from scratch. This will be good in the long run.