Re: [Geotools-devel] FeatureType equality (and troubles in JDBC land)

[Andrea A. <aa...@op...>]

Bryce L Nordgren ha scritto:
> 
> Andrea Aime wrote on 12/29/2006 01:00:32 AM:

> "Schema assist" is not necessarily tied to GML.  Drawing out your feature
> model in a UML class diagram with all the geospatial and non-geospatial
> attributes is known as an "application schema".  This is a quite flexible
> and robust means of planning any data you intend to share, and lets you do
> pretty much anything you can do when you're designing software.  Your
> features can have data.  They can also "have relations" with each other
> (associations, aggregations, and compositions).  And they can have
> behaviors/operations.

Classes, associations, behaviours, lazy loading.... hmmm, look, I've 
spent the last 4 years developing Hibernate based applications, and this
sure looks a lot like Hibernate to me.
See here: http://www.ohloh.net/projects/55
Hibernate is 340.000 LOC (code only), most of which are dealing with 
associations, collections, lazy loading, type mapping and the like. Are 
we ready to go down this route and replicate this kind of behaviour with 
our Feature classes and data store?

> GML schemas deal only with the data model + associations.  They are not
> equipped to handle a full feature model simply because they cannot transmit
> behaviors.  

GML is just a transport mechanism, no wonder it does not transmit
behaviour. Behaviour can be transmitted (think RMI class loading) but
I feel we are going off topic?

> Starting from this point, it's not hard to see that the "schema" contains a
> complete description of the feature, while the memory resident version of
> the feature contains some part of the feature (usually the data).  We have
> to allow the memory-resident version to not have certain things which the
> schema does have.

Well, that's what I call a projection.

>  Once we do that, we must have some means of combining
> the data part of the schema with the behavior part.  Once we have this
> architecture in place, we could certainly apply it to missing data items.

When I was working with Hibernate, I had lazy loading abilities on 
associated objects. The moment I started using them, I also gave up some
behaviour, because once disconnected from the session you gave up lazy 
loading too (and for good reason, the moment you leave your transaction 
you loose isolation, if you lazy load one minute later, you're loading
stuff from a different database, and building a possibly inconsistent 
data Frankenstein).

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

I don't get it. If it lacks data, if it's a projection, it's not the 
same feature. If it lacks operations, the same applies, it's not the 
same. Same to me means completely replaceable. Remove a property and 
your ability to replace is gone.

> 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.  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 would handle this in a slightly different way, which seems more 
natural and more in line with our existing code.
1) Joining different feature types, compute new attributes -> something
    like "complex data store", that is, define a new feature type as
    full Query, where Select is made of Expressions, From is made of
    feature type references and join conditions,
    and Where is a set of filters against the various feature types
2) Reducing the number of attributes is something we already do.
    A view in SQL does not allow to ask for extra attributes that are
    not in the select clause.

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

Define dumb. I've spend a lot of time explaining people telling that
Hibernate sucks because it does thousands of queries during certain data 
processings just because they did not tell it what to load in advance
and relied on lazy loading instead. All of these guys had a computer
science degree.
Give enough rope to your users, and they'll find a way to hang 
themselves up.

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

If by users here we are talking about programmers (since geotools is a 
library) I trust the programmer to know the difference between the full
stuff and the projection of it.

> 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'm a bit lost. How is ViewFeature different (and more convenient) than 
creating a new Featuretype with less attributes?
I'm also not convinced that when you remove attributes you can
keep on saying you still have the same feature type... to me it's a 
different one.

Cheers
Andrea