On 3/4/10 10:06 AM, Andrea Aime wrote:
> 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.
I think we are misunderstanding each other. All i am saying is that if
the user wishes to update the schema with another attribute, or drop an
attribute, etc... then the code ends up calling updateSchema(). If the
user actually wishes to delete the schema then the code ends up calling
deleteSchema(). If we want to be cautious we can only call
deleteSchema() if a "purge" flag is set.
>
>> 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?
>
Yeah to make things easier on the client. Perhaps the client does not
care where the new data layer ends up in the workspace / datastore
hierarchy. Or maybe the admin does not want the client to know because
they want the freedom to change it.
All the client wants is a place to create new layers. In this case it
would be nice to not have to burden the client with (a) knowing ahead of
time what the default workspace and datastores are or (b) having to
parse through configuration to find out dynamically what they are.
Anyways, a hypothetical use case to be sure so not a strong argument. It
would be nice to have the input of a client side developer who would be
building an application against this functionality.
>
> 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.
Works for me.
>
> 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.
Agreed. But I just think we need to be explicit about the differences.
Remapping is a publishing concern whereas updating is a resource
management concern. I guess if we had the resource pub split it might be
a bit clearer.
>
> 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
