PartitionFeatureStore

I have an idea ... datastore.getView( filter ) makes use of ....

    public FeatureSource<SimpleFeatureType, SimpleFeature> getView(final Query query)
        throws IOException, SchemaException {
        return new DefaultView( this.getFeatureSource( query.getTypeName() ), query );
    }   

Where DefaultView (donated from GeoServer - thanks!) carefully combines queries as needed:

    public FeatureCollection<SimpleFeatureType, SimpleFeature> getFeatures(Query query) throws IOException {
        DefaultQuery mergedQuery = makeDefinitionQuery(query);
        FeatureCollection<SimpleFeatureType, SimpleFeature> results = source.getFeatures(mergedQuery);
        ....
    }

I would like to create something similar this - used to "partition" a large shapefile or database table that has had a type system imposed on it. Specifically there is an attribute (say "type") that is used to partition table contents and mark rows that belong to a specific class; the fact that they all have same attributes is an accident of history; they still represent different content.

I am not sure if this is a common enough case to be useful? It is more that I would like to do this code in GeoTools in the data module rather then hidden away in uDig.

The idea would be to do what DefaultView does; using:

• attribute name to partition on
• value "selected" for the partition being returned

Rather then simply use DefaultView - I would like the result to be a FeatureStore (ie editable) for all rows where type="foo".

So for FeatureStore methods:

• addFeatures - would need to add the "selected" value for the partition attribute to the supplied values (ie type="foo")
• modifyFeatures - would need to include the selected value in the filter
• deleteFeatures - would need to include the selected value in the filter

And for FeatureSource methods:

• getSchema - should hide the partition attribute - and possibly renamed so getSchema indicates what the partition value is
• getFeatures - should strip out the partition attribute

PartitionFeatureStore could be wrapped around any FeatureStore. We would probably need a second implementation to wrap around FeatureSource for consistency.