Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.
Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Task #9315 (new)

Opened 10 years ago

Last modified 10 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.


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?


Change History (9)

comment:1 Changed 10 years ago by jmoore

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:

  • 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.

Last edited 10 years ago by jmoore (previous) (diff)

comment:2 Changed 10 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 10 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 10 years ago by jmoore


Last edited 10 years ago by jmoore (previous) (diff)

comment:5 Changed 10 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 10 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 10 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 10 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 10 years ago by rkferguson

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

Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.67635 sec.)

We're Hiring!