> 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

Reply via email to