Gabriel Roldan ha scritto:
> 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?).
It is there actually, in DataAccess:
/**
* Used to update a schema in place.
* <p>
* This functionality is similar to an "alter table" statement in
SQL. Implementation
* is optional; it may not be supported by all servers or files.
* @param typeName
* @param featureType
* @throws IOException if the operation failed
* @throws UnsupportedOperation if functionality is not available
*/
void updateSchema(Name typeName, T featureType)
throws IOException;
> 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.
Wait, I said DataStore.dropSchema(String typeName).
DataAccess would have dropSchema(Name typeName) instead.
Given our existing code it would seem quite odd to see string used
everywhere and then suddenly a Name for dropping a schema in
data stores.
For newer API that wants to use DataAccess and is ready to take
the overhead of using Feature methods instead of SimpleFeature
the DataAccess.dropSchema(Name) would be there.
> 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.
This is similar to Jody's point. However, we don't have anything like
that for createSchema and updateSchema either.
Such a capabilities API should probably also provide some hints on how
type and attribute names are transformed by createSchema to make it
possible to create a data transfer tool (which today is hard to
implement as Oracle and SDE tend to mangle the provided names).
I see this as scope creep in this specific proposal, though I would
love to see someone make a separate proposal on a capabilities
api for datastores (similar to the one we have for feature sources
in terms of query capabilities).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
