Hi Andrea, Il giorno ven, 12/06/2015 alle 05.20 +0200, Andrea Aime ha scritto: > On Thu, Jun 11, 2015 at 1:04 PM, Stefano Costa > <stefano.co...@geo-solutions.it> wrote: > > > 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?
As a matter of fact, I do have a draft implementation of the former: https://github.com/geoserver/geoserver/compare/master...ridethepenguin:app-schema-rest I'll frankly admit the code is not pretty, so I'm very much open to suggestions on how to improve it :-) > 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). > As per the documentation, a PUT request to the endpoint: /workspaces/<ws>/datastores/<ds>/[file|url|external][.<extension>] will "upload files to the datastore (in our case, the mapping file), creating it if necessary". For example, I successfully created a new app-schema datastore issuing this PUT request: curl -X PUT -d @LandCoverVector.xml -H "Content-Type: text/xml" -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/lcv/datastores/LandCoverVector/file.appschema?configure=all where LandCoverVector.xml is an app-schema mapping file containing the mappings for two feature types, LandCoverDataset and LandCoverUnit. The datastore was successfully created and the feature types in it correctly configured, thanks to the configure=all request parameter. > > 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? I tested this use case and (I believe) the service did the right thing, without app-schema specific code, updating the url in the datastore.xml file to point to the location of the uploaded mapping file. The only glitch I saw here was that the mapping file was stored outside the datastore directory $GEOSERVER_DATA_DIR/workspaces/<workspace>/<datastore>, under $GEOSERVER_DATA_DIR/data/... My hand-crafted datastore.xml file went like this: ... <entry key="url">file:workspaces/lcv/LandCoverVector/LandCoverVector.xml</entry> ... I issued the request: curl -X PUT -d @LandCoverVector_alternative.xml -H "Content-Type: text/xml" -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces/lcv/datastores/LandCoverVector/file.appschema?configure=none where LandCoverVector_alternative.xml is a mapping file with slightly different mappings for the same feature types (no need to configure them again, so configure=none) As a result, the datastore.xml was updated as such: <entry key="url">file:/home/stefano/Lavoro/GeoSolutions/projects/hale/geoserver-2.6.2/data_dir/data/lcv/LandCoverVector/LandCoverVector.appschema</entry> I issued a couple of WFS requests to confirm that the mappings had been updated, and in fact they were. Now, this worked out nicely because the feature types in the two mapping files were exactly the same: in case the new mapping file contains new feature types or omits some that were present in the old mapping, perhaps the best way to update the configuration would be to DELETE the entire store and create it again issuing a PUT request with the new mapping file in the body and the configure paramter set to all. What do you think? > > > Cheers > Andrea -- 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 Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
