Hi all,
in GeoServer we have had for ages an inconsistency between what we present in the UI, store wise, and the actual behavior for creating stores, that I’d like to make consistent.
UI wise, one goes to create a store, and chooses a specific store type, getting its associated form. When enumerating the available stores, one also has certainty about the store type, and it’s consistent with what was chosen in the GUI:
So far so good, but when the actual creation happens, things can take another route.
Let me give you some code pointers.
Finding the Store type
The above page populates the “type” column calling ResourcePool.getDataStoreFactory(storeInfo)
The method first checks the StoreInfo.getType (e.g., GeoPackage), and looks it up based solely on that, matching with the display name of factories. If that does not work, then it falls back on using the connection parameters.
This fall back is useful and important, it allows to plugin an alternative factory that can handle the same parameters, allows for code upgrades (e.g, old jdbc stores vs ng ones, as it happened a few years ago).
Creating the store
ResourcePool.createDataAccess is responsible for creating the store. It first looks up a factory by name, does some checks on it (and actually throws an exception if the factory is not found) and then… throws everything away and creates the store by just using the parameters!
The above situation is normally consistent because we try to have stores with parameters that are different enough, that two store won’t collide… but it’s pretty fragile, and indeed it broke, because the FlatGeoBuf store, does not have one of those discriminator fake parameters…
and the result is this:
https://osgeo-org.atlassian.net/issues/GEOS-10824
Now, we can add a discriminator to FlatGeoBufDataStoreFactory, or we might try to check for well known FGB extensions, sure, but these all look like workarounds for a simpler, more basic deficiency: as a user… I’ve already told GeoServer exactly what it should be using, and it even saved my choice… why would it try to guess it again? (especially after having looked up the factory by name anyways!)
What I’m proposing is a very modest change: in ResourcePool, while creating the store, if a factory has already been successfully looked up, please try to use it first, and fall back on the current dynamic lookup only if that fails. It’s a few lines change that should make both developer and user experience better. And I’ll also change it so that if the factory is not found, it won’t throw an exception (because really, it shouldn’t, it should try the dynamic lookup instead).
Objections?
Cheers
Andrea
···
GeoServer Professional Services from the experts!
Visit http://bit.ly/gs-services-us for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions Group
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
https://www.geosolutionsgroup.com/
http://twitter.com/geosolutions_it
Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail