Task #9315 (new)
Opened 12 years ago
Last modified 11 years ago
RFE: OMERO database setup is two steps when it could be one
Reported by: | rleigh | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | Unscheduled |
Component: | Deployment | Version: | n.a. |
Keywords: | n.a. | Cc: | ux@… |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | n.a. |
Sprint: | n.a. |
Description
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
Change History (9)
comment:1 Changed 12 years ago by jmoore
comment:2 Changed 12 years ago by 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?
comment:3 Changed 12 years ago by 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!)
comment:4 Changed 12 years ago by jmoore
(dupe)
comment:5 Changed 12 years ago by 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).
comment:6 Changed 12 years ago by 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.
comment:7 Changed 12 years ago by 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.
comment:8 Changed 11 years ago by jmoore
- Cc ux@… added
- Milestone changed from OMERO-5 to Unscheduled
- Owner jmoore deleted
- Summary changed from Bug: OMERO database setup is two steps when it could be one to RFE: OMERO database setup is two steps when it could be one
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.
comment:9 Changed 11 years ago by rkferguson
I think this would have to rate pretty low on my priority lists too.
The first usage is already 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:
But it doesn't seem like a huge win, to be honest.