> 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). 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). 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
