> 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

Reply via email to