Agreed, they will be hints for JDBC for DataStore, but app-schema would probably need to treat them as explict configuration, which might then subsequently need to be smuggled as hints to the underlying JDBC store. As you say, shouldnt affect the proposal but we may want to update app-schema afterwards to take advantage of the capability, which is pretty much fundamental to all app-schema mappings.
Will have to look at this in more detail when you've done - its not our biggest priority. Rob On Tue, Apr 13, 2010 at 4:29 PM, Andrea Aime <aa...@opengeo.org> wrote: >> 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
