+0 here
Short question, do we know if a jdbc-ng store is based on a view or
table. The delete statment would be different. ?
Another issue is, that in case of a programming error, one could
delete a datastore.
Am not sure here, leaving the decision to the other members.
Quoting Andrea
christian.muel...@nvoe.at ha scritto:
+0 here
Short question, do we know if a jdbc-ng store is based on a view or
table. The delete statment would be different. ?
That's why I wanted to have supportsRemove(Name name) in the
capabilities instead of the methods that do not take a name.
christian.muel...@nvoe.at ha scritto:
Hmmm, using the jdbc metadata object we could determine if a store is
based on a table or view. I see no problems dropping a view.
Err... I think I need another coffee this morning... of course there is
no problem dropping a view...
Cheers
Andrea
--
Thanks for the explanation Andrea.
+1
Michael
--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
I am happy with the explanations and the no go with shapefiles: +1.
Simone.
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
Hi,
and here is the proposal to add the remove schema API to trunk:
http://docs.codehaus.org/display/GEOTOOLS/Add+ability+to+remove+feature+types
Votes and opinions are welcomed!
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
looks clean, seems a change that is not very intrusive.
I would say I am +1, but of course I will wait to see welcome from
people more involved into the vector side of the geotools world.
Questions, are there any plans with regards to Shapefiles?
Simone.
Hi Andrea,
Sorry if this is a dumb question... This will only be supported by the
JDBC data stores - is that correct ?
Michael
--
___
Geotools-devel mailing list
+1. This make sense, and will allow more flexible use of this class.
There is one slight implementation complication: app-schema allows
multiple definition of feature types, to allow nested (feature chained)
types to used in different ways for different properties. Our
interpretation of the
Simone Giannecchini ha scritto:
looks clean, seems a change that is not very intrusive.
I would say I am +1, but of course I will wait to see welcome from
people more involved into the vector side of the geotools world.
Questions, are there any plans with regards to Shapefiles?
I won't
Michael Bedward ha scritto:
Hi Andrea,
Sorry if this is a dumb question... This will only be supported by the
JDBC data stores - is that correct ?
I plan to initially implement it only for JDBC data stores.
Other stores might go and implement it as well in the future. Examples:
- shapefile
Ben Caradoc-Davies ha scritto:
+1. This make sense, and will allow more flexible use of this class.
There is one slight implementation complication: app-schema allows
multiple definition of feature types, to allow nested (feature chained)
types to used in different ways for different
12 matches
Mail list logo
