+1 as well as far as I know this is never something that has been implemented properly or well tested.
In ContentDataStore I attempted to implement it by having ContentFeatureSource be able to "join itself" to another query / view. But again never tested it. -Justin On 5/3/10 7:22 AM, Jody Garnett wrote: > Thanks Andrea: > > One think I notice with both this proposal and your caching feature source is > that we could really stand to have a stable of features source wrappers to > roll out. I don't have my heart set on accessing them all from DataUtilities; > but I can see the attraction of not defining more new public API. > > So yeah I use getView(); but can migrate to a DataUtilities.createView( > source, query ). > > +1 > > > Jody > > > On 03/05/2010, at 11:01 PM, Andrea Aime wrote: > >> This is actually from Michael, I just moved into its own >> thread to make it more visible: >> >> http://docs.codehaus.org/display/GEOTOOLS/Remove+DataStore+getView+method >> >> Cheers >> Andrea >> >> -- >> Andrea Aime >> OpenGeo - http://opengeo.org >> Expert service straight from the developers. >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Geotools-devel mailing list >> Geotools-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
