[Geotools-devel] Re: DataStore (or chris's mad plan)

[Chris H. <ch...@op...>]

> >Ok, I'm having trouble figuring out how to reply to all of these thoughts, 
> >and should do a nice combined email like Jody's, but I'm just going to 
> >start replying.  
> >  
> >
> Just a idea perhaps we could use CVS to communicate a bit more, we do 
> have a branch after all and nothing communicates like code :-)
I agree.  We need to start using the branch more.

> >As for catalog, I looked a bit through ogc catalog specs over the weekend.  
> >I don't know that I like the implementation one too much, I may have to 
> >look at it some more.
> >  
> >
> I have made a Catalog class in the data module on the data-exp branch 
> where we can start to figure out
> our requirements.
I'll check it out.

> >added to the Collection, but making it more flexible, so that an added 
> >Feature can validate against one of a number of FeatureTypes.  This would 
> >mirror a GML document, as Features of different Types can appear in the 
> >document, as long as they are specified in the Schema.  We could just 
> >handle this functionality in the FeatureCollection, allowing the Type of 
> >the typed collection to have more than one FeatureType (a method like 
> >addValidatingType(FeatureType)).  Or we could introduce the concept of a 
> >FeatureSchema, that contains more than one FeatureType.  This 
> >FeatureSchema could turn itself into a GML Schema, and it could be used as 
> >an AttributeType as well, validating more than one FeatureType.  I don't 
> >know if it's really necessary if DataSource is to just have one 
> >FeatureType, which it looks like that's where things are going.  But it 
> >still is a concept that might be worth looking into.  It pops up in my 
> >mind every once in awhile, but I never have a really compelling reason to 
> >try to implement it.
> >  
> >
> I like the symetry of an FeatureSchema to accept more than one 
> FeatureType to capture your idea. It mirrors your GML use. I was going 
> to add FeatureDocument but I see that it already exists in the feature 
> module, what are your intentions?
Correct me if I'm wrong Ian, but that was basically our intention.  The 
FeatureDocument was meant to mirror GML.  It was to be a subclass of 
FeatureCollection, with a typing policy.  I do agree with Sean's point 
that the FeatureDocument name is less than ideal.  But I've got nothing 
better, except for the vague thought to have FeatureSet be our root, with 
FeatureCollection subclassing it with a typed policy.  This would match 
gml more closely, but the java collections hierarchy less cloesly.  So I'm 
not sure that I like that either.  Or perhaps TypedFeatureCollection.  I 
think the importance of this class depends on where our streaming is done, 
in FeatureCollection or just directly in FeatureReader, at least from my 
perspective, since my use for it is in GML Producer, as I can then know 
what the expected FeatureTypes of Features in a collection are going to 
be, and I can put the appropriate GML Schema information in the header.

> >So to hash out more specifics, where do modification methods take place?  
> >The FeatureStore obviously still has them, does it get the direct 
> >connection from the DataStore and do its own modifications? DataStore 
> >would provide attributeWriters, and FeatureStore would use those to do 
> >add/remove/modify, but use connections or other hooks to do remove and 
> >modify more efficiently if possible?  Is that the general thought?
> >  
> >
> You seem to have to right of it (I was starting on the high end towards 
> the middle which now seems to be where we are).
> - The wrinkle you are missing is the Transaction - it will need to cache 
> a connection which the FeatureStore will use for modification. If there 
> is no current Transaction the FeatureStore can grab one from the Pool 
> maintained by the DataStore and perform the opperation using 
> AttributeWriters. This is the added functionality that the FeatureStore 
> buys us (that and a simplified API).

Cool.  I like it.

Ok, time to finish up my initial wms move, and then I'll start digging 
into the code.  Thanks for putting it up on cvs Jody, good to get us 
actually working there.



	Chris