Hi Martin,
thanks a lot for the explanation.
On the topic of data source. The use case of updating credentials is not really
needed at this time.
It was just a nice thought. I will try your workaround.
Clearing the cache would be a good feature, I think. Or something like a forced
option to not use the cache.
We can create a Jira ticket if you want so that this idea doesn't get lost.
Just let me know where to do that.
There is a difference in the WKT string between cached and requested EPSG code.
So it is clear which "source" was used.
```
Request
Id["EPSG", 32634, "9.9.1", URI["urn:ogc:def:crs:EPSG:9.9.1:32634"]]]
Cache
Id["EPSG", 32634, URI["urn:ogc:def:crs:EPSG::32634"]]]
```
Another question has come up for me.
You mentioned that I can use it to check the status of Apache SIS
```
System.out.println(org.apache.sis.setup.About.configuration());
```
Is there an easy way to get the column entry for a geodesic dataset as string
to compare the result to a pattern? I am stuck with the getRoot() and
getColumns() methods.
I have 3 possible situations that I want to check.
1. Correct Version and everything is fine.
```
Local configuration
├─Versions
│ ├─Apache
SIS…………………………………………………………………………………………………………………………………………………………………………………………………………………………
1.2
│
├─Java…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………
11.0.17 (Azul Systems, Inc.)
│ ├─Operating
system…………………………………………………………………………………………………………………………………………………………………………………………………………
Linux 5.15.0-53-generic (amd64)
│ └─Geodetic
dataset…………………………………………………………………………………………………………………………………………………………………………………………………………
EPSG geodetic dataset version 9.9.1 on “PostgreSQL” version 14.4.
```
2. Not supported Version because user imported wrong version.
```
Local configuration
├─Versions
│ ├─Apache
SIS…………………………………………………………………………………………………………………………………………………………………………………………………………………………
1.2
│
├─Java…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………
11.0.17 (Azul Systems, Inc.)
│ ├─Operating
system…………………………………………………………………………………………………………………………………………………………………………………………………………
Linux 5.15.0-53-generic (amd64)
│ └─Geodetic
dataset…………………………………………………………………………………………………………………………………………………………………………………………………………
EPSG geodetic dataset version 10.076 on “PostgreSQL” version 14.4.
```
3. No imported Database so I have to give a totally other feedback.
```
Local configuration
├─Versions
│ ├─Apache
SIS…………………………………………………………………………………………………………………………………………………………………………………………………………………………
1.2
│
├─Java…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………
11.0.17 (Azul Systems, Inc.)
│ ├─Operating
system…………………………………………………………………………………………………………………………………………………………………………………………………………
Linux 5.15.0-53-generic (amd64)
│ └─Geodetic
dataset…………………………………………………………………………………………………………………………………………………………………………………………………………
Untitled
```
Greetings
Florian
Am Mittwoch, dem 16.11.2022 um 11:49 +0100 schrieb Martin Desruisseaux:
>
> Hello Florian<br>
> <br>
>
> Le 16/11/2022 à 01:27, Florian Micklich a écrit :<br>
> <br>
> >
> >
> > Is it possible to recall the setDatabase method? For example the
> > db settings are set via variables and can be updated by the user
> > during runtime.
> > So I want / have to update the Configuration.current() as well.<br>
> Currently setDatabase(…)
> does not allow allow to change the data source after it has been
> initialized, for reason given in next paragraph. As a workaround,
> it is possible to achieve a similar effect by providing a custom
> implementation of DataSource
> interface, with a field which is the real PGDataSource
> (if using PostgreSQL) and with all methods doing redirection to
> that PGDataSource. That way, the
> value of that field can be changed and it will be taken in account
> the next time that DataSource.getConnection()
> is invoked.<br>
> An issue is that the new data source will not be
> taken in account immediately. SIS keeps JDBC connection open a
> little bit (in case there is many consecutive uses of EPSG
> factory, which is often the case at least in SIS internal) and
> closes it only after 1 minute of inactivity. So the new data
> source would be taken in account only after the user stay one
> minute without requesting any EPSG codes. For avoiding this delay,
> we need to force an immediate release of JDBC resources after the
> data source changed:<br>
> ```
> ConcurrentAuthorityFactory<?> factory = (ConcurrentAuthorityFactory<?>)
> CRS.getAuthorityFactory("EPSG");
> > factory.close();
> > ```
>
> Note: there is also a factory.setTimeout(…)
> method if you want to change the 1 minute timeout to something
> else.<br>
> Above workaround is not perfect. If there is any
> CRS cached in memory, they will not be updated by above change. It
> is technically possible to improve setDatabase(…)
> for allowing cleaner change, which would include flushing the
> caches. If there is a need for that, I suggest that we create a
> JIRA issue.<br>
> Martin<br>
> <br>
> <br>
