Hi Andrea, thanks for your answer, see my comments inline. Il giorno mer, 10/06/2015 alle 20.31 +0200, Andrea Aime ha scritto:
> In the REST api those are two different use cases. In vector stores, > you PUT a shp/property/h2/spatialite to create a new store, > and the file location you provides is filled as part of the store > creation parameter maps. > If there store is there and you are created a new feature type, you > instead POST to that feature type with a schema definition, > and the code will call createSchema(). > > > From the docs App-schema seems to be taking the url to a configuration > file, if so, I guess you could just modify the > existing DataStoreFileResource to handle that case (like, spatialite > is not a core module anyways, but since > everything is working via strings and maps, you don't really need to > add dependencies). I tried to modify DataStoreFileResource as you suggested and the first hurdle I bumped in is that, as the name suggests, the implementation is based off DataStoreFactorySpi/DataStore, while app-schema uses directly DataAccessFactory/DataAccess. I tried to replace all instances of DataStoreFactorySpi/DataStore with DataAccessFactory/DataAccess and it didn't turn out so bad... not sure though if this is the best way to do it; another possibility that comes to my mind would be to create a DataAccessFileResource, that DataStoreFileResource would then extend. > I'm not totally clear with the details though, like I guess you also > need to include the schema and so on in the > zip file you're sending or not? AFAIK, it's not strictly necessary: if the mapping file contains a URL pointing to a remote schema, the app-schema plugin will download it and put it in the app-schema cache at first access. > > > Adding a mapping to an existing store instead, uh, not sure what to > answer to that one, it does not look that app-schema > has any facility to add feature types at runtime, looks like you have > to update the main config file and rebuilt the > app-schema store... Yeah, that's exactly what I had in mind, at least for now: no possibility to add new feature types at runtime, just allow for a full rewrite of the mapping file the store is based off, which implies replacing the existing feature types with the ones described in the new mapping file. If replacing the mapping file, with all that this implies, doesn't work out, clients could just resort to dropping the datastore and creating it anew. > Logically it would seem the code handling this would have to go around > this area: > https://github.com/geoserver/geoserver/blob/master/src/restconfig/src/main/java/org/geoserver/catalog/rest/FeatureTypeResource.java#L86 > > > > Or else, maybe you can register a new resource under: > > > /workspaces/{workspace}/datastores/{datastore}/featuretypes/{featuretype}/mapping > > > > That would be a special handler for just the app-schema mappings, a > GET would return the mapping, a PUT would > create it, and as a consequence, create the FeatureTypeInfo as well? Sounds like a good idea to me, but, as I wrote above, I'd be content with much less for now :-) > > > Cheers > Andrea > > > -- > == > GeoServer Professional Services from the experts! Visit > http://goo.gl/it488V for more information. > == > > > > Ing. Andrea Aime > > @geowolf > Technical Lead -- Best regards, Stefano Costa == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Dott. Stefano Costa Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
