>>> Do you think that "schema-assisted" object model mapping is a
>>>
> reasonable
>
>>> compromise - as long as we have the extension points to extend the
>>> schema with object libraries - such as GML primitives, coverage
>>> primitives, custom operations
>>>
>> Guys, speaking from an OO and library point of view, can't we consider
>> XML just an I/O format? Forcing XML schema right in our object model
>> as ways to get extra information strikes me as something we should
>> really want to avoid.
>>
>
> Amen!
>
>
I agree too, but point out our code is doing the opposite of this...
Consider this: we are reading the persistence schema to deduce a
"Feature Type" (old way) or reading the GML schema to define it (complex
datastore). The issue is how do we import the feature model we want to
work with? The idea of schema-assist is to read the schema to describe
the data structures we have to manage, then allow matching these to
object libraries to add behaviours.
>> GML is definitely the most flexible format, and our OO model should
>> be at least as expressive as GML, but I don't see why we would want
>> "schema-assist" it (which I may be misunderstanding, but feels like
>> having feature types gathering extra informations from a schema?).
>>
>
> I think I might understand what Rob is getting at. Let me explain my
> thoughts, and Rob can correct me if I'm putting the wrong words in his
> mouth.
>
You're a few steps ahead of me in terms of practical realisations, but
the underlying separation of data persistence from the feature itself
seems correct. I'm actually focussed on very short term (next step)
practical issues however - I want to make sure we dont hard code in too
many incorrect assumptions. However, sjip to the next point.
...
> So I think Rob has this bigger picture in mind, and "schema-assisted" is a
> means of matching up a complete schema ("feature type") with an associated
> in-core feature instance which has only some of the schemas attributes.
> After all, if it's "the same feature" even when it lacks the ability to do
> stuff, it should still be "the same feature" when it lacks a data item or
> two. Data and Operations are all properties.
>
>
This is the real point - where do feature type definitions come from,
and how do we make implementations as robust and simple as possible
>
>
>>>> If the feature reader returns a partially resolved feature, how are
>>>>
> the
>
>>>> resolved attributes distinguished from the unresolved ones?
>>>>
>>> private flag I guess.
>>>
>> Alarm! Layering violation! layering violation! The model knows about
>> persistence!! :-)
>>
>
> My thoughts too.
>
> What about this:
>
> Define a "ViewFeature" as a GeoTools utility (as in a "view" in SQL). This
> feature maintains an association with a particular feature reader and can
> handle representing a particular subset of attributes. THis utility would
> implement the Feature interface and GeoAPI isn't touched. You could
> implement multiple attribute caching strategies in several concrete
> children, or you could let the user compose the utility with a caching
> strategy object at run time.
OK - but with any caching strategy you have a situation where the model
(data viewed through the cache) knows about persistence (do I have this
cached or do I get it). What you dont have is the model knowing about
_how_ the persistence is managed by the provider.
And, if the reader gets the data for feature (a row in a result set,
say), then a view exposes part of it, and then a client accesses one or
more attributes, then moves on to the next feature, you have still got
efficient streaming. Its only if you build the whole feature collection
then decide you need additional attributes that would hurt. So Bryce's
idea that you get all the attributes needed to support a specific View,
then simply avoid processing the data unless you need it seems
reasonably efficient.
> Heck, in general the View could be made up
> from many different source FeatureTypes. Or it could calculate values for
> a field not in the original data set (or just provide a field in which to
> store the results of a per-record calculation).
>
I like this - remember my point was that "ReTyping" was inaccurate
naming... what we have is a "view" into an underlying feature (which is
_not_ the persistence layer based "anonymous FeatureType" one IMHO). If
this view is able to encapsulate mappings we do have a more flexible and
realistic model, that we can keep consistent with the current code base
by continuing to pretend that we will make the persistence-layer derived
FeatureType into a meaningful real (externally published) FeatureType.
With this fiction, we can maintain backwards compatibility with current
behaviour, without being crippled by its assumptions for too long.
> If reality bites the user on the head because they are using an
> inappropriate data access strategy, that user needs to get smarter.
> There's no cure for dumb users. We'd only need to populate the toolbox
> with "likely-to-be-useful" tools.
>
> This idea is actually the opposite of Rob's injecting/merging philosophy,
>
I'm not sure it is - I was focussed on injection of types during the
FeatureType creation, not during the resolving/reading process.
> but I think it may be a more natural fit to the original question about how
> to handle queries for some but not all of the data attributes. (Without
> requiring major design or implementation efforts.) It's just easier to
> throw data away than to try and "match up" a data fragment with an
> all-encompassing schema.
>
>
OK - this is whats happening currently - we have a JDBC result set and
then we start throwing bits away by partial mapping
>>>> This seems to argue for
>>>> considering unresolved attributes permanently unresolved, which would
>>>> merit
>>>> a different feature type.
>>>>
>>>>
>>>>
>>> I think this is not a new feature type, but maybe an error if you dont
>>> ask for everyhting you will need, maybe its OK for the feature instance
>>>
>
>
>>> to throw an exception if an unresolved attribute is accessed? I'd
>>> rather correct behaviour than start managing vague definitions.
>>>
>> This is a lot better, but it seems to me more sensible to have an
>> extra feature type. Let's tackle this from a GML angle: you are removing
>> attributes, maybe attributes that are mandatory in the original feature
>> type. Hence, your "reduced" feature type is not the same as the
>> original, the XML schema that defines it is different, no?
>>
>
>
If you have an extra feature type, you have to define it. This is an
overhead, currently handled by only allowing subsets of the persistence
schema derived by black magic from the context of the query. Not a good
place to be if you want to make something behave smarter - for example
support a coverage operation, or convert a linear reference system
position into a cartesian coordinate set, or average a set of readings
over a time period.
> It could go either way depending on what the user wants to consider "equal"
> at run time. They may want to ensure that all attributes corresponding to
> the feature are present. They may just want to know that the data which is
> present came from a particular feature type. They may not care one bit
> about what feature it came from, but it must be "elevation data" or "land
> cover data" or whatever.
>
> I think making an org::geotools::ViewFeature should give the user enough
> ways to figure out the "equality" they want without hiding a paticular
> meaning of "the same feature" behind an equals method. Since the names
> aren't the same ("ViewFeature" != userFeature) they aren't the same
> feature, but ViewFeature.source() could reference the feature type which
> provides the original data definition.
>
> I particularly like the fact that GeoAPI is not touched. It should also be
> a good example to library users: "see it's OK to write your own
> implementation of the Feature interface."
>
>
I think thats the nub of it - not assuming we have a new FeatureType,
but simply creating a view.
> Oh well enough for today.
>
> Bryce
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
