Good stuff, this is something I have thought a little about over the
last while. Here are some of my random thoughts:
* DataStore.deleteSchema()
I think I would prefer adding a deleteSchema rather than overload the
meaning of updateSchema... even though in most cases that is how a
datastore would implement updateSchema, first dropping then creating.
How about adding the deleteSchema() method to a few of the abstract data
store base classes (like ContentDataStore) without explicitly adding it
to the interface. Then of course we would have to call the method
reflectively and bomb out in cases where it does not exist.
Then when we go to a new major GeoTools version we pull it up into the
DataStore interface.
* Attribute length restrictions
If creating a new schema via an http ("rest") call we are stuck to
representing what AttributeTypeInfo allows us to represent. Which leaves
out length restrictions and other restrictions.
Perhaps we can just leave this is as a limitation of the http interface.
Or perhaps we modify AttributeTypeINfo and add a length field.
* Default datastore
I was thinking that it would be nice to add a concept of a default data
store to a workspace, just like we have the concept of a default workspace.
And like workspaces we add a "symbolic link" called "default" which is
accessible via http GET/POST/PUT. For example:
GET http://.../workspaces/topp/datastores/default.xml
And when creating a new schema a user can:
POST http://.../workspaces/topp/datastores/default/featuretypes/
Or they can explicitly specify a datastore:
POST http://.../workspaces/topp/datastores/myDataStore/featuretypes/
Or perhaps just rely on all the server defaults:
POST http://.../workspaces/default/datastores/default/featuretypes/
-Justin
On 3/4/10 7:22 AM, Andrea Aime wrote:
> Hi,
> in OpenGeo we're looking into adding in GeoServer the ability
> to create new feature types from a user provided description
> by leveraging the data store createSchema(FeatureType) call.
>
> With this mail I'm trying to provide some ideas on the how
> and gather feedback.
>
> The main idea is to have a GUI that allows one to compose a
> feature type description and an equivalent REST call.
> The GUI could be placed in the "new layer chooser",
> now we have a
> "add layer from"<datastore>
> selection, I guess we could have a couple of radio buttons
> instead providing also a
> "create layer into"<datastore>
> or something like that.
>
> The GUI would then offer the ability to add attributes,
> name, data type, nullability and length.
>
> The REST api would allow to POST a description of
> the feature type to
> /workspaces/<ws>/datastores/<ds>
> The description would come in the same formats
> supported for the feature type
> (see
> http://docs.geoserver.org/2.0.x/en/user/extensions/rest/rest-config-api.html#feature-types)
>
> This would make it quite a bit easier to start
> from scratch and allow data editing.
>
> Two things that are rolling in my mind are also how
> to possibly handle something as simple as the human error.
>
> Say I made a mistake in the structure of the feature type.
> How do I go and correct it?
> DataStore and DataAccess provides updateSchema(), though I'm not aware
> of any datastore actually implementing this call. For
> a datastore
> DataStore is also missing dropSchema() method, which sounds
> quite like a strong limitation to this use case... I mean
> being able to create a feature type by GUI and then have to go
> on the database and issue a drop table manually seems backwards.
> Dropping is also much simpler to implement than updating.
> How do we go about to add this functionality though?
> Shall we roll a new interface that contains only that method?
> Or create a DataAccess2, DataStore2 subinterfaces that contains
> it (oh the horror).
> Or... but please be seated before reading this one... hijack
> updateSchema and assume the user meant to delete the feature
> type when we call updateSchema(Name, null)?
>
> The second thing is, would it make things easier if we mark
> a datastore as the "default" and then have all schema management
> calls hit it?
>
> Cheers
> Andrea
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
