Message-ID: <17987369.23817.1412071990907.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_23816_1475653396.1412071990907" ------=_Part_23816_1475653396.1412071990907 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Disscussion goes here:=20
This is from an email entilted 'Bring back the FeatureCo= llection!' In it Chris Holmes argues
that a way our of our results/re= ader mess is to make use of this nice
FeatureCollection construct we = came up with, and then promptly relegated
to memory only. Note you sh= ould have your coffee before reading this.
Thinking in the shower this morning I decided to take a look at our
The main thought is that FeatureResults was created to give a very simil=
construct to a FeatureCollection (though streaming), and perhaps w= e could
just take it back in that direction.
Right now FeatureCollection is sort of a code word for an in-memory
collection, we went to featureResults to ease the transition to streaming= .
But I'm thinking we should just take back FeatureCollection. Have DefaultFeatureCollection become MemoryFeatureCollection, and change
DefaultFeatureResults to DefaultFeatureCollection.
Ok, on further thought it would need to be DefaultTypedFeatureCollection=
The main (useful) thing that FeatureResults does that FeatureCollec= tions
do not is return the FeatureType. So we introduce the notion of= a
TypedFeatureCollection (something IanS and I thought about but nev= er
implemented). The TypedFeatureCollection would only allow Features= that
validated against the FeatureType.
Of course this gets into interesting questions, if the default is to all=
multiple types in the feature collection, or demand a new interfac= e for
that. And then there are also interesting questions of combinin= g two
TypedFeatureCollections. A construct like that would be ver= y useful for
GML production, as you could get at all the Feature= Type info directly from
a single FeatureCollection construct.
Ok, I'm rambling into further implications, to bring this back to the
positive aspects of this decision, FeatureReader and FeatureIterator ha= ve
similar parallel structures . Reader will return the FeatureType. = And it
additionally has the close() method. But note that our Feature= Iterator
does not implement java.util.Iterator, so we can ad= d the close method.
So we can also introduce a TypedFeatureIterator, = that will return the
FeatureType, and FeatureReader can simply implem= ent that as well.
One thing to note is that FeatureCollection has quite a few more methods=
than FeatureResults, since it extends Collection. But one thing to n= ote
is that most operations are optional in the Collection interface.= The
only none optional ones are contains, containsAll, equals, hashC= ode,
isEmpty, iterator, size() (which is actually FeatureResults.getC= ount(),
and toArray(). All of which could be implemented fairly easil= y.
DefaultFeatureCollection could change to take a Query and a FeatureSourc=
as it's constructor, in short it would just expand on
Doing this also gives us a nice interface for random access, in that a FeatureList would implement list, and provide get(int index), indexOf(=
and lastIndexOf(). So FeatureSources that support random access co= uld
return List implementations, and clients could then check to see = if they
got a list. Or there could be an explicit getList(), which wo= uld build a
random access index for an unordered collection. Check ou= t
feature/FeatureIndex.java, for some more interesting ideas that Ian= S had.
Granted we would probably need a TypedList, could possibly be = done nicely
by making a Typed interface, which just has a method Feat= ureType
getFeatureType() (or FeatureType getFeatureTypes(), should = decide what
the default behaviour is).
Another thought is that all FeatureCollections would be typed, =
in some way. In this case the in memory FeatureCollection (o= r any
FeatureCollection that allows any FeatureType), would make use = of the
ancestor stuff that we have implemented, all in it would be of= type
Feature (I'm not exactly sure how this works, but I'm thinking = along the
lines of the SLD stuff, that all must descend from Feature,= no?). This
gives a nice little constraint on what a FeatureCollectio= n is vs. a normal
collection . it must contain features. So the getSc= hema method would
always return at least a Feature FeatureType. I thi= nk to get this to work
well we'd have to introduce some type of OrFea= tureType . that is a
validation mechanism that can check against more= than a single
featureType. Perhaps a Schema class, of which a featur= eType represents a
single instance of a feature. But a Schema could a= lso have multiple
FeatureTypes. Each Schema class could have a getFea= tureTypes() call, and
a FeatureTypeSchema (with just the one), could = return itself. I think the
key (and potentially only) method of a Sch= ema would be the validate()
method. FeatureType does not currently ha= ve a validate method, but
DefaultAttributeType.Feature does, I think = perhaps we should again
contemplate FeatureType implementing Attribut= eType. Or at least have both
descend from a common Schema class.
(Skip this section if you're having any trouble with all of this and rea=
it over later)
If we have both from a common schema class the= n this also generates some
more interesting questions. Like what we d= o about MultiAttributeTypes.
Because a MultiAttributeType is in some = ways a FeatureCollection
(especially if FeatureCollections offer a va= lidate method). For a quick
review, a MultiAttributeType was my const= ruct to basically handle a list.
Never really been used (but I will w= hen we get to joins), but it's for
when there is more than one object= in an Attribute, think maxOccurs
greater than one in XML . you can p= ut a bunch of little objects in there.
In the easy to grasp case you'= d have more than one sub features, literally
a TypedFeatureCollection= . all would be the same type, each in the list
would have to validat= e against the same FeatureType. But they also could
be any sort of ob= jects, they could be strings (think all the names of
people living at= an address). This is a list of objects that must
validate against so= mething in common (all must be strings). So maybe we
could have a Val= idatingCollection, of which FeatureCollection is a
subType. Ok, my id= eas are straying here, but one thing to think about is
maybe putting = in hooks for more complex validations . we already have this
field le= ngth thing, which is fairly meaningless. I believe David was
going to= do some work on this for his schema stuff, basically it'd be nice
to= have in the central api a way to express more complex validations that
we don't currently support).
(end skip section)
Of course, doing this does beg some more interesting questions, like wha=
if we actually implemented the Collection add and remove. I mean, i= f the
FeatureSource backing it is a FeatureStore, then an add or remo= ve could
easily update the backend data format. Of course, this obvio= usly gets
messy, when we take into account locking and transactions a= nd also the
CollectionListener code we have (though I don't think it'= s really been
used, and actually could potentially give us a way out = of this problem).
The one question that remains is backwards compatibility, if we can pull=
it off. I'm hoping that re-using a few constructs we already have ca= n
help ease this pain. But the main point is that we should take thin= gs
back to this great paradigm that IanS brought to the fore, of real= ly
making use of the Collection framework. It makes it far, far easie= r for
java programmers to get acquainted, they can just see that getF= eatures()
returns a Collection, and they instantly know what to do wi= th it, and then
from there can learn the more optimized ways of doing= things.
FeatureCollection myFeatures =3D
Feature myFeature =3D myFeatures.features().next();=
Also, a potentially interesting idea for FileDataStores . having it
implement FeatureSource? Or rather maybe call it SingleDataStore? It
just might be cool if you could say
SingleDataStore store =3D new ShapefileDataStore(myUrl);
Feature m= yFeature =3D store.getFeatures().features().next();
(semi(un)related thoughts, just to get people started on what I'm going =
write up next)
Ok, one last thought for everyone to ponder .= the file and directory
datastore question brings this up. Basically = the thought of a
multi-datastore, what happens when you combine two d= atastores? It could
still easily implement DataStore, just with more = featureTypes, right?
When we get into joins and views it does start t= o beg the question of what
a DataStore actually is. Especially when y= ou add datarespository and
discovery stuff (is that stuff gone now? I= haven't been able to update my
repository, and it's still all over m= y DataStore). I don't have any
coherent thoughts on all this, but we = should really think about what a
DataStore is, and I think we should = maybe split it up into more
interfaces, instead of the current direct= ion of adding ever more methods,
so that each interface represents cl= early what the DataStore is, and what
you can do with it. Perhaps som= ething like PhysicalDataStore, which
FileDataStore and JDBCDataStore = extend, and then a parallel
VirtualDataStore, that is the result of c= ombinations of DataStores (or
perhaps that can also return 'views'). = And/or a MultiDataStore, which
DataRepository could then extend, and = add the locking functionality.
Discovery could then extend DataReposi= tory or something. Speaking of
which I would still appreciate a write= up of the 'discovery' functionality
that Refractions needs, and what= their metadata plans/needs are, as I
never got that explanation in t= he IRC from David. At the very least I'd
like to be sure we are on th= e same page of what metadata means.
(end semi(un)related thoughts)
Ok, enough for today. Next up for me I will examine some of the question=
I raise above, especially the implications of FeatureViews (my init= ial
thoughts are actually in the direction of taking out QueryAs and = only
giving people As access in FeatureSources), and how to go about = decoupling
Features from the data sources they are defined in (mappin= gs and joins and
whatnot). I think it'd be really cool to take James'= s idea of defining
common FeatureTypes even farther, so you could def= ine your FeatureSource
by the FeatureType you wanted, and supply it w= ith an appropriate mapping
object (and an object on what should be ma= pped from, the join to perform,
the table to select from, the bypassS= ql statement, ect.)