Hi again, I think there are two different requirements being mixed here (or maybe I don't fully understand the point): 1- defining the database to be used (embedded or external, database directory, database name, etc) 2- getting a connection to the defined database
For the second one, I think it would be enough to place a getDataSource() method somewhere in the API. As SIS is suppose to be already configured, it will be able to return the DataSource. For the first one, I don't know the full SIS picture to figure out the best option. If I correctly understand the code, at the moment you try to get a JNDI context if available. Otherwise, you try to use Derby EmbeddedDataSource to open (and potentially create) a database named "SpatialMetadata" on SIS_DATA (if available) or on "derby.system.home" otherwise. I think it is fine to delegate on the SIS user the decision to provide a JNDI context or to set SIS_DATA or derby.system.home. When an external database should be used and JNDI is absent, I think the most standard way would be to provide a JDBC connection string. It would also be nice to be able to provide SIS_DATA as a Java property in addition to the environment variable. Finally, I wonder if it makes sense to have several configured databases (for instance for providing CRS definitions from a different authority), although I understand that in this case I would just register the authority factory and SIS doesn't need to know about the database internally used by the authority. Best regards, César On 6 February 2018 at 10:19, Martin Desruisseaux < [email protected]> wrote: > Hello César > > Le 05/02/2018 à 18:57, César Martínez Izquierdo a écrit : > > I think that JNDI may be relevant to specify the database used by a > specific SIS deployment. > > Yes, but an issue is that there is no JNDI environment by default in a > standard Java installation. JNDI environments come with container like > Tomcat. We could provide our own micro-JNDI environment when none is > present (it is not difficult to do), but wasn't sure we want to go that > path. > > > For the user case I was describing, I think the method you cited > (Initializer.getDataSource()) is more than enough (and also generic), as I > just want to launch queries against the configured database (whichever it > is). However, it will be useless if it is not visible on Java 9. > > In Java 9, it it still possible to bypass the restriction with an option > given to Java on command-line. Even with restriction enabled, that > functionality can still be available in next SIS version; we just need to > decide how (JNDI or otherwise). A possible approach may be to use > Initializer.getDataSource() for now, and switch to the public API later > after we provided one. > > > In any case, now I realise that for a particular deployment, if I know I > will be using epsg with derby, I can just create a new data source to > "SpatialMetadata" database, using Java standard procedures. > > The difficulty is to determine in which directory is located the database > (unless using the embedded database, or the default Derby location). I > would suggest to use Initializer.getDataSource() instead, and try to > agree on a public API for next SIS release. I opened a JIRA issue if anyone > want to comment on that: > > https://issues.apache.org/jira/browse/SIS-395 > > Martin > > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - César Martínez Izquierdo GIS developer - - - - - - - - - - - - - - - - - - - - SCOLAB: http://www.scolab.es - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
