Yeah, the flexibility of letting the system choose has not really been taken advantage of.
Is a change needed at the geotools level also? -- Jody Garnett On Mon, Jul 15, 2024 at 8:52 AM Andrea Aime < andrea.a...@geosolutionsgroup.com> wrote: > 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: > > [image: image.png] > > 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 > <https://github.com/geoserver/geoserver/blob/d215cb8708bf8706601c19cc2037c02128b33106/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L608> > ) > 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 > <https://github.com/geoserver/geoserver/blob/d215cb8708bf8706601c19cc2037c02128b33106/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L696> > 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 > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel >
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
