I will create a JIRA task with attached files (initial JUnit test and basic method implementation) tomorrow.
My opinion that it would be nice to have a general interface method like: DataStore.modifySchema(String typeName, AttributeType[] removedTypes, AttributeType[] addedTypes, Expression[] addedValues); It gives more freedom and avoids an artificial creating new FeatureType, passing it into updateSchema(FeatureType newFT). updateSchema(FeatureType ) may parse passed FeatureType comparing it with existing and delegate call to the actual implementation of schema modification functionality at modifySchema(..). Also modifySchema(..) method can not be in DataStore API, but each data store implementation can have its own implementation of this method. It needs casting to use this method from particular data store implementation but: in custom projects usually it is known a prior what the data store is used. I mean such kind of functionality "usually" is applied to the well-known data store implementation in well-known use cases (not in general way). And the old updateSchema(...) can still exist in API. Let's try to add modifySchema(..)/modifyFeatureType(..) to the ShapefileDataStore and updateSchema(..) will just delegate its job to modifySchema(..)/modifyFeatureType(...). The real use cases (usage of this functionality) confirm the right direction to move. Vitali. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:geotools-devel- > [EMAIL PROTECTED] On Behalf Of Cory Horner > Sent: Tuesday, October 17, 2006 3:10 AM > To: [email protected] > Cc: Vitali Diatchkov > Subject: Re: [Geotools-devel]ShapefileDataStore.modifyFeatureType(...) > improvement > > Vitali Diatchkov wrote: > > >I would like to see a method > > > >public void ShapefileDataStore.modifyFeatureType(AttributeType[] > >removedTypes, AttributeType[] addedTypes, Object[] defaultAddedValues) > >throws IOException; > > > >for modifying current ShapefileDataStore schema. > >... > >I have implemented the method, also tests. Any comments or suggestions > >(for/against this proposal). > >If there are no points against I can commit to geotools 2.2.x branch and > to > >trunk. > > > > > Vitali, I agree and would like to see this implemented (why can't other > datastores just toss "not implemented" exceptions...). > > Can you send us a patch, or attach it to a jira for review? > > Cheers, > Cory. > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
