RFE: OMERO database setup is two steps when it could be one

[rleigh]

The installation instructions require the following:

$ bin/omero db script
$ psql -h localhost -U omero omero < OMERO4.4__0.sql

However, is there really a need for this do be done in two steps? Why can't "bin/omero db setup" (or equivalent) just create everything directly, either by piping the output script to psql, or by connecting with jdbc and running it natively? Is there any need to have a copy of the script, other than for debugging purposes?

The same applies to upgrades. Wouldn't "bin/omero db upgrade" be easier?

Regards,
Roger

[jmoore]

The first usage can certainly be covered by: bin/omero db script -f- "" "" ome

And we could definitely add a "upgrade" command which will print the appropriate (current) upgrade script.

The reason we don't invoke psql is because of the variability of installs, paths, etc. I could imagine adding an "--execute" flag which would use:

• the first psql on the path
• the omero.db.* settings from bin/omero config

But it doesn't seem like a huge win, to be honest.

[rleigh]

I was really just thinking about reducing the complexity of the installation. After all, OMERO already has to have all the correct connection details in order to function, so is there a reason to run psql directly if it's not needed, given that it could just do all this itself?

[jmoore]

The PG installation need not be on the same host as the OMERO server. In that case, the connection information which is allowed to use the database may not be able to create new databases. That's just one example though. By simply providing scripts, it seems we minimize the number of edge cases that we have to explain, though where people know what they are doing, I'm ok with having OMERO provide more features. (Though, that won't simplify the docs!)

[jmoore]

(dupe)

[rleigh]

Sure. But at this point in the install, we've already created the database, and it's assumed to be up and available. If it wasn't, we wouldn't be able to run the script. We just need permission to connect and have write permission to create tables etc. (which we do, as the owner). This is not changing the requirements/prerequisites in any way; it's merely automating a single step, and can be run on any host which can access the database server (since it can use the configured settings to connect).

[jmoore]

For just the case of piping the script into psql, I agree completely. And as I said, that's supported now with "-f-" (which is perhaps one step too much). The more advanced usage where we reduce things even further is more what I was talking about, since I assumed you wanted to remove psql from the docs completely.

[rleigh]

At least for the Windows install, there is no use of psql other than this step (the rest being done via pgAdmin), so this avoids the complication of having to run psql, since it's unlikely to be in the path etc. For other systems, it's likely to already be in the user path and so less likely to cause difficulties, but even then it's a little simpler.

[jmoore]

Gus: don't know if this is also something you're interested in getting involved in.

Though I see Roger's general reasoning, I don't see this 1) as simple as it's made out to be across platforms, etc. and 2) pressing at the moment. (I may be completely wrong though, since I'm CLI-pain-intolerant). Taking my name off of it and pushing to "Unscheduled" as an RFE.

[rkferguson]

I think this would have to rate pretty low on my priority lists too.