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&#174; 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&#174; 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