Justin Deoliveira ha scritto:
> 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.
Ouch, wouldn't this result in loosing all the data?
In database terms, I would be more favourable to a alter table
than drop and create.
Shapefiles could have to create the new type with a different name,
copy over the data as possible, destroy the old and rename the new.
> 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.
Sounds like a good plan to me. I think that by covering ContentDataStore
and AbstractDataStore we actually have the methods in most of
the actual datastore implementations.
And yes, calling it reflectively allows stores that do not extend from
any of the above (ArcSdeDataStore, PreGeneralizeDataStore)
to still expose such method and have it called.
> * 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.
Not having the length for strings might end up being quite a limitation.
Afaik we default to 255, which might be way too much (e.g., the field
is supposed to contain the values 'A', 'B', 'C') or not enough (if
the field contains a narrative).
So I would rather go and add it as a new feature.
There is also the problem we also don't have a clear way to
differentiate between VARCHAR(x) and TEXT. I guess past this point
people will just have to drop the GS facilities and go use native
tools to create the types.
> * 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/
Scratch scratch. I'm having a hard time getting why the
default is important (I hesitantly mentioned it in my first
mail because it was something that was in the air about this work).
The reason I have for having the default workspace is to allow people
to avoid prefixing layer names in OWS requests.
What is the reason for having a default store? Avoiding to remember
its name when doing REST calls, building a client that just does
not know anything about existing workspaces and stores and still
be able to create a layer?
On a different note, if we have also the ability of dropping and
updating, where do we exercise it?
If we have dropping I guess we can skip updating for the
moment and simplify the implementation a little.
But dropping... where? Maybe in the layer feature type section?
A button that allows to kill the layer and also its underlying
resource for good?
Updating, if implemented, could go in the same panel.
Things could get a little confusing however the day we also
have remapping, that is, changing the name or the type of a
column for publishing. This would look a little like updating,
but we would not actually change the structure of the
underlying storage.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
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
