Re: [Geotools-devel] AbstractJDBCDataStore and its pilot implementation for Oracle Spatial

[Rob A. <ro...@so...>]

Cool, just a few last comments, confirming your analysis.
> What I see here. Hibernate do not know a priori about how to bind hierarchy
> of objects to relational model. We should configure it (through XML or
> annotations) and charge the framework with such configuration. Is complex
> feature type a thing that represents such a configuration for feature model?
> I mean feature type that describes complex entity some of attribute types of
> which are nested feature types? As I understand this is a complex feature
> model.
Yes, but a better way of thinking about it is as its new name "community 
schema support" - the feature model is governed by the data transfer 
schema you are trying to support. These tend to be "complex" because 
they will refer to other standard features (often), relevant metadata 
(usually) and elements from other namespaces (eg gml:name)  (always).

In this case, we read the XML schema to determine the feature model, and 
augment it with bindings of concrete types to abstract types where the 
schema has generalised elements.

>  I did not follow a lot to complex feature model discussion.  But if
> there is a such configuration (like complex feature type) then there is a
> way to implement complex features binding to database relational data model.
>
>   
We are currently doing the binding in a wrapper data store, with limited 
functionality. I think that we could probably support most of the 
binding more elegantly with a stronger JDBC data store, based on the 
full feature model. Only truly complex features should need a wrapper, 
where there are multi-valued complex attribute types, or joins to 
related feature types that share configurations.
> We charge the framework with configuration of complex feature types, binding
> starts to work. So, as I understand, this is mostly about configuration, how
> to model complex relationships, then complex features binding implementation
> may be general enough to work with any general configuration. Like we
> provide XML schema and XML document begins to be not only text, but
> structural information for third parties (parsers e.g.)
>
>   
>> Possibly this can/should be abstracted to a different level of the
>> architecture, but keen to see whether you have thought about this at all.
>>     
>
>
> When there is no user provided configuration described above, the only SFM
> is available for JDBC features binding (table to feature type, row to the
> feature) in automatic way. If there is a general mechanism to model complex
> relationships then we may implement more complex binding. But I am not aware
> about complex feature model progress a lot. So, that's why my understanding
> of these things are intuitive right now.
>   
just the ability to map SFM into multiple namespaces, and to choose the 
elements from the table, and to be able to invoke functions and joins 
would help enourmously, and would suit many simple schemas without 
further capability (Simple Features Profile Level 0)