Hello Adam, On Fri, Mar 16, 2012 at 4:07 AM, <adam.br...@csiro.au> wrote: > Hi Gabriel, et al., > > With regards to the structure of the new ContentDataStore type (and indeed, > others throughout GeoTools); I'm curious as to why the constraint on Simple > types is not deferred to the terminal nodes of the hierarchy?
For ease and historical binary compatibility I guess. If DataStore doesn't type narrows to SimpleFeature/Type, then there'd be no difference between DataStore and DataAccess. At this point you might be wondering there actually is a difference, since there are methods in DataStore that do not exist in DataAccess. Reason is again convenience, in order not to bloat the DataAccess interface (introduced as a super type of the already existing DataStore when complex features got into the mix) with transactional methods (getFeatureWriter, etc) that at the time didn't have a single concrete implementation nor we were sure they'd be of use for the complex features case. If at all, a transaction capable DataAccess implementation can return FeatureStores instead of plain FeatureSources to support data modification. If/when DataAccess.getFeatureWriter and any other extra method present in DataStore and not in DataAccess is proven needed/useful, then those could be added to DataAccess. Meanwhile it was thought it'd be better to be conservative. At least that's my understanding. Hope that helps. Cheers, Gabriel > > > > For example, the current structure is like this: > > DataAccess<T : FeatureType, F : Feature> > > DataStore : DataAccess<SimpleFeatureType, SimpleFeature> *** > Constraint on Simple features is imposed here. > > ContentDataStore : DataStore > > WFSContentDataStore : ContentDataStore > > > > Whereas this approach seems to provide more flexibility: > > DataAccess<T : FeatureType, F : Feature> > > DataStore<T : FeatureType, F : Feature> : DataAccess<T, F> * > Perhaps 'Store' should be renamed to something else so that it doesn't imply > SF. > > ContentDataAccess<T : FeatureType, F : Feature> : > DataRepository<T, F> > > WFSContentDataAccess<T : FeatureType, F : Feature> : > ContentDataAccess<T, F> > > WFSContentDataStore : ContentDataAccess<SimpleFeatureType, > SimpleFeature> > > > > I'm not sure if this code is just tightly-coupled to simple features because > support for complex types hadn't been considered or if I'm missing some, > more important, reasons for why the code is structured like this? > > > > Thanks for your help, > > > > Adam Brown > Software Programmer | CSIRO Earth Science and Resource Engineering > > Phone: +61 8 6436 8956 | > adam.br...@csiro.au | www.csiro.au > Address: Australian Resources Research Centre, 26 Dick Perry Avenue, > Kensington WA 6151 > > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
