Le 06/02/2018 à 11:38, César Martínez Izquierdo a écrit : > I think there are two different requirements being mixed here (…snip…): > > 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. > Yes, it may be the most pragmatic approach.
> 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. > Right. > 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. > Since JNDI is standard and "derby.system.home" is defined outside SIS, the SIS_DATA environment variable is currently the only SIS-specific configuration alternative. We avoided adding other SIS-specific alternatives for now (e.g. a SIS_DATA property) because having too many ways to configure the system makes client support more difficult. In our experience with Geotk, when a user reports a problem related to EPSG dataset, in most cases the cause is SIS selecting a different database than the one the user thought. So I agree that we may need to provide different way to configure SIS, but I think we should be careful to not add too many ways and wait to identify the most useful ones in practice. I agree that a JDBC connection string is one of those. > 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. > Yes. In addition of different authorities, it can also be different versions of the same authority. For example you can have many versions of EPSG databases. SIS automatically detects version numbers and takes than in account when users ask for codes like "EPSG:8.2:4326". But the current approach is that SIS manages by default only one database - SpatialMetadata - with many schemas in it, and let the definition of other databases to users. Martin
