Re: [Geotools-devel] Dropping feature types

[Gabriel R. <gr...@op...>]

Looks good to me. Some methods were left out from the DataAccess API on 
purpose, under the assumption that they might need some more discussion 
so we better keep the API minimal (looking at it I'm not sure why 
there's an updateSchema method already?).

dropSchema(Name typeName) looks straight forward enough, but I'd argue 
against dopSchema(String typeName). That'd be just an utility method for 
the case where Name.getNamespaceURI() == null, as DataAccess is all 
about Name, not just simple name ==> String.

Also, I would prefer a query methods, say, canDrop(Name 
typeName):boolean, instead of leaving users left to trial and error on 
an unchecked exception.

My 2c.-

Gabriel
On 4/22/10 7:29 AM, Andrea Aime wrote:
> Hi,
> I'm writing this mail to get some preliminary feedback on the idea
> of adding, on trunk only, a DataAccess.dropSchema(Name typename)
> and a DataStore.dropSchema(String typename) methods allowing the users
> not only to create and update schemas, but also to drop them.
>
> If a datastore decides not to support the methods it will just
> throw an UnsupportedOperationException.
>
> The changes I have in mind will make so that the base classes we have
> (AbstractDataStore, ContentDataStore) just throw an exception,
> which should cover pretty much the whole code base with the exception
> of the app schema store, and then provide a simple drop table
> implementation for JDBC-NG datastores.
>
> How do people feel about this?
> It is an API break for datastore implementors, but an easy to fix
> one and it will hit only whoever implemented the stores directly
> from the interfaces (daunting, I doubt it will actually affect
> many people).
>
> If there are no strong objections I'll go and prepare a proposal for
> this.
>
> Cheers
> Andrea
>
>


-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.