fix #970, #12317: adjust dbpatch table; delete map values with triggers

[mtbc]

Fixes http://trac.openmicroscopy.org.uk/ome/ticket/970 and http://trac.openmicroscopy.org.uk/ome/ticket/12317. Broken tests not of this PR are fixed by @ximenesuk in #2892 and ome/omero-scripts#91.
--no-rebase

To test:

1. create a fresh DB
2. observe the contents of the configuration and dbpatch tables
3. start the server
4. see that a DBEnumCheck entry is added to both tables
5. check that the server is running okay
6. restart the server
7. see that both tables have nothing new from the restart
8. check that the server is running okay
9. import some images
10. see that we thus have some map property entries in the database, e.g., in the uploadjob_versioninfo table
11. delete some images
12. see that the corresponding property map entries are deleted.

[mtbc]

Could I have a breaking label added, please?

[mtbc]

Are the --depends-on being ignored by OME-5.1-breaking-push?

[sbesson]

No, apart from being informative, --depends-on is only parsed by scc travis-merge to include multiple PRs in the breaking queue, they all need to be labelled as breaking.

[mtbc]

Ah, thank you, good to know.

Well, this PR seems to be consistently all green apart from the tests that @ximenesuk kindly fixed after #2847 broke them: want to remove the breaking label so that it goes into tomorrow's merge for review, or review it first separately in breaking?

[bpindelski]

One thing I noticed is the random appearance of

PersistentEventLogLoader.v2.current_id  |-1
pixelDataEventLogLoader.v1.current_id   |-1

in the configuration table. Once it appeared on the first start of the server, the other time - on the restart.

[bpindelski]

Besides the comment (#2893 (comment)), the code changes look OK. Good to merge.

[jballanc]

@bpindelski As I recall, setting those values to "-1" is a signal to the indexing system that the entire event log needs to be reindexed. At least, that should be the case for PersistentEventLogLoader.v2.current_id. I'd have to look at the code again to say for sure if the same is true of pixelDataEventLogLoader.v1.current_id.

[mtbc]

Thank you, @jballanc: yes, this PR oughtn't affect these *.current_id configuration keys.

[bpindelski]

@jballanc Thanks. In this case, the appearance of those rows doesn't cause any problems. Good to merge.

[mtbc]

I suppose before merging, try a merge build without the breaking label?

[joshmoore]

Definitely. breaking removed.

[ximenesuk]

Does this need any further testing in the non-breaking build or is that it built good enough for merging?

[mtbc]

I don't know, but somebody else will.

[joshmoore]

I'm assuming based on the lack of explosions today on trout that this is good to go. Thanks, all.