This is a fairly important issue - you guys have much greater familiarity than I do with the internal assumptions - but it strikes me that the public ID and the internal table primary key are fundamentally different things, and we're trying to collapse them into a single concept.
Simply, I think we need the ability to make the feature id from any property, and ignore the primary key, which may be a composite key. There is a contract that there is a unique feature id for each pk - its merely a convenient default that the pk can be used as a feature id because of the uniqueness constraint, but as Andrea's business requirement demonstrates its not the general case, or a remotely safe assumption if we are going to see interoperability based on WFS. The ability of the external system to define the referential integrity requirements using id generation policies is an unavoidable architectural requirement. FYI In app-schema we also have some issues - we can map any column, or function over a set of columns, to the feature id, ignoring if necessary any internal table pk, but we haven't addressed issues of transactions. We're starting to look at the issue of efficent queries against functions - i.e. inverse functions that can be used. 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. In the meantime, getting our heads around the differences between data in private database tables and objects referenceable by the outside world is a hugely valuable step, so if there is a workable tweak, its useful. Rob On Tue, Apr 13, 2010 at 2:08 AM, Justin Deoliveira <jdeol...@opengeo.org> wrote: > On 4/12/10 9:10 AM, Andrea Aime wrote: >>> While I realize that some users have this problem I generally still >>> think it is a bad idea to make any promises about supporting inputting >>> of ID's. >> >> Not promises, just have a way for the datastore to state if it >> can or not use the provided ids. >> >>> What about the notion of a wrapper datastore that can basically >>> maintain mappings in a table (similar to how versioning ds uses tables >>> to maintain versioning info). >> >> Not acceptable when you're trying to line up forgeign keys, the >> relationships are mantained only if you use the provided one. >> >> Not acceptable either if you have organisation provided pk generation >> policies (I'm not making this up, I actually have a paying customer >> asking for this). > > Just an off hand idea. If it won't work it won't work. >> >> In the versioning data store I had to make this possible for equally >> reasonable needs. I just don't have a way to expose that capability, >> it is an undocumented feature that only GSS uses. >> >>> It would also0 have the nice side affect of not further complicating >>> the jdbc ng code which has seen a wack of features and development >>> over the last year. Not a bad thing of course but the more we add to >>> it the more monolithic and harder to maintain it becomes. >> >> The modification required is actually smaller than the "defined >> feature types by sql query" as far as I can see, it would be likely >> less than a 100loc change (I did not look into this in detail, I admit). > Cool. Again not against bigger changes I just think that a lot of moving > parts of accumulating there. Lucky we have good testing in those modules. > >> >> Cheers >> Andrea >> >> > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
