Note java version info on imports.

[mtbc]

This changes the model. To test, import images and watch the filesetversioninfo table in the DB.

[joshmoore]

Thanks for taking this on, @mtbc. I'm a bit hesitant to add a table named javasystemproperty; it's certainly in line with the filesetversion table, but perhaps we can come up with a more generic strategy rather than several separate tables.

[mtbc]

A more generic version of javasystemproperty that wholly supersedes filesetversion?

[mtbc]

(Also, am I correct in assuming that the fileset version info instances may be created by clients that are wholly non-Java?)

[joshmoore]

A more generic version of javasystemproperty that wholly supersedes filesetversion?

Something like that. Would require some brainstorming, but this is starting to feel leaky.

(Also, am I correct in assuming that the fileset version info instances may be created by clients that are wholly non-Java?)

Definitely.

[mtbc]

Well, I'm happy to turn filesetversioninfo into something more like javasystemproperty. Or, something else. Do you want to think about it and, when you figure something else you'd like me to try, I'll have a go at it? Or we can include it in one of our hangout chats with others.

[joshmoore]

Best to just discuss soonish.

[mtbc]

Something more like this, then?

[joshmoore]

In principle, yes. But, in discussion with @chris-allan, there's a good chance that we will want to increase the number of such properties that are catalogued here, meaning that our (private thread) bullet point 4 may be the best way to go.

@mtbc, would you be wiling to try putting these in a dynamic column similar to Pixels.params. If possible, these could be exposed as a (read-only?) Map similar to the map of counts on Image, etc. Trying out hstore (rather than the regular arrays used by Pixels) would be beneficial.

I'm currently marking as excluded because I already created a dbpatch=2 DB (for your changes) in gh-951. If you could base on top of that PR and use dbpatch=4, I'll be sure not to conflict.

[mtbc]

Another separate table was too simple, huh? (-: Sure, I'll give hstore a try, but given that I'm only here another week before taking time off, I'll prioritize today's bruker bug from Gus and the server side of import-time checksum selection for Blazej, so fixing this might get postponed. Thanks for the pointer to the similar existing example, though, that'll probably much speed things up when this again bubbles to the top.

[joshmoore]

Sounds like a good plan, thanks.

[mtbc]

So, this will need extra code in Property.java and a new ParameterizedType implementation used by PostgresSqlAction?

[mtbc]

I'm wondering if this should be turned into a ticket so that its completion can be properly scheduled in the appropriate sprint.

[joshmoore]

It's noted in http://trac.openmicroscopy.org.uk/ome/ticket/10807, but if you would like to create a separate ticket in OMERO-5, feel free. Closing this PR.

[mtbc]

These weird column types probably prevent our using an in-JVM DB for integration tests. ):

[joshmoore]

As discussed with @rleigh-dundee, @qidane, and @jburel, we will likely be relying on such column types more in the future.

[mtbc]

Superseded by mtbc@617b74e.