On Thu, Jun 11, 2015 at 1:04 PM, Stefano Costa < stefano.co...@geo-solutions.it> wrote:
> > 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 guess the latter is better, or at least, it sounds more in line with how the difference between store and data access is often managed, but if you already did the former, that works too, could you share a link to a github diff for it? > > 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. > > Nice. > > > > 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. > Ok. So... normally you would use the POST operation to create a new store, but a PUT operation to update an existing one. I believe that rigth now we have PUT in terms of updating the StoreInfo xml config, but not a version of it that would replace the "source data" (where in app-schema, the closest equivalent seems to be indeed the mapping file, as everything else is already registered as its own store in GeoServer). Also, what happens if you are trying to update a config file for a pre-existing app-schema store that was hand-crafted (and which might have a different path to the config one, than the one the rest path mappers would like to use for your store?). In general, it may seem you'd need to roll some custom behavior to locate the right mapping file based on the existing configuration, which would make for app-schema specific code. How are you going to handle it? Cheers Andrea -- == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 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 Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
