> There is probably a danger that such emerging requirements push the > DataStore API into evolving into another version of DataAccess. I'd > personally be against major changes to DataStore that duplicate the > improvements in DataAccess, in favour of paying the technical debt to > either upgrade to DataAccess (or provide auto-config and UI tools for > app-schema - to publish the introspected schema as a template config > that can be massaged) and test transactions via it.
I don't see how this is going to happen for the case we're discussing here. If we go for the hints I was suggesting in previous mails, those will have to be respected by both DataAccess and DataStore. Even assuming that DataAccess could do transaction (even if it won't for a long time as far as I can see) how would it help? A JDBC data store would either hide the primary key or alternatively expose it but make those columns read only, so DataAccess would not have any way to interact with it write wise anyways. Even assuming DataAccess was there and usable for transactional work, the proposal would not change a single bit, it would just make the implementation harder as I'd have to fix the complex data store as well. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
