Hi Andrea, I am going to brain dump here as you have been away for a while and missed out on some of our learning from the FM branch. I apologize for the writing I did not have time to make it smaller .... > Hi Jody, > I kind of understood that you want to make feature collection more > "powerful" > and move things like sorting (and joins) on that one, removing those from > the Query. It is a split between Query model (ie Query) and data model (ie optimized implementaitons of FeatureCollection).
Query represents a high level request (ie please answer this question), and as such is very limited in what it will *ever* be able to accomplish. Currently we take our inspiration from WFS1.0 (with a couple things like reprojection, and hacks to force CRS. Not a scalable approach, and data store writer would never be able to keep up with the changes as our needs grow as a library. We have had a couple experiments down this front, most recently Query2 as an extension directed at supporting joining. The problem involved two conflicting concerns: building a data model and then selecting content out of it. For Query 2 we had a the following data model concerns: - definitions of target data sets (ie list of typeNames refering to data sources to be joined) - redefinition of the data model (using a bunch of "As" expressioned used to list "attributeA" as "attributeB" (in order make the attribute names line up to be joined on) - other model manipulations (like forcing the projection of individual geometry attributes, or reprojecting geometry atributes (so later spatial based selection could function). This is what I mean by "constructing" or "prepping" a data model. And for a Query model we have good old Filter (for selection of matching features), and the traditional Query construct (so we can indicate which attribtues we want back, and the maximum number of results). We also need to add SortBy into this mix. I would also ask that we include the CSW Query ideas so we can "page" through data (so both a max number of results, and a starting number). This is what I mean by a "query model. Our early attempt with Query2 failed as we tried to pre-judge all the desirable manipulations that would be needed to set up feature collections from different sources to be joined. In a sense we were constructing a single data model, and allowing a single query to be run against it. We also made some bad choices about trying to define a language (using interfaces at the same level as filter) to describe the manipulation of the data model, this was made especially hard as we needed to manipulate the FeatureType as well as the data. What I want to do this time is split these two concerns between different classes. - Data Model is *always* handled by FeatureCollection methods (and FeatureList as required) - Implementations are free to use their internal model to represent the manipulations required (JDBC implementations would obviously use SQL fragments, I would recommend Shapefile uses FID set based "selections" to which boolean logic can be applied and so on, probably combined with internal chains of feature manipulation at the visitor level). - Query Model is *always* handled by parameters to feature collections methods (ie FeatureCollection.subList( filter ) and FeatureCollection.sort( SortBy) ) So what of the class "Query"? It represents a nice high level construct, directly matching WFS 1.0 (and soon WFS 1.1). At a library level it *may* be wise to remove it from a usibility standpoint (less to learn), but I suspect keeping it around as a utility class would be okay and would offer geoserver a nice bridge. So what of the requested class "Transaction", ie if Query is good for GeoServer why not take the Transaction method over as well? I agree it would make a nice high level helper class, it would allow geosever to offload more complexity and would allow some applications an easy way "batch" changes for later. (indeed if you were doing versioning having access to a record of Transaction objects is the way cascading WFS is implemented by Galdos) > Any other thing you want to move? A couple points of reference: - Query needs to be "just" a request, processing the query should be done by making calls to the FeatureCollectoin classes. Both to allow data store authors the ability to produce optimized code, and for consistency. The recipie of turning a Query into a set of FeatureCollections method calls should be methodical (and from the WFS specification). - Each DataStore will need 4 FeatureCollection implementations that should be optimized (I have sent the description of these out before, and they are document in GeoAPI and FM branch javadocs) - What of FeatureReader and FeatureWriter - they represent a very nice low level construct, currently AbstractDataStore is build as a tower of abstraction over top of these bases, I would like to see us implement the middle this time (and offer up FeatureReader and FeatureWriter as an iterator over a FeatureCollection produced by the above mentioned script for handling a Query - FeatureLock and Feaure creation (with respect to FID generation), we are still using the first generation solution, GeoAPI documents the second generation, as per the FM branch we need to bring this solution home so that FID and Lock handling reflect the mechanics of a distributed data. > Besides that, what is the advantage of such a move? Less code, clear boundaries following the split between data model and query model, and at a pragmatic level less abstraction in the data store implementations. For the other things like FID generation and Locking they are just fixing known mistakes. > Cheers > Andrea Jody ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
