Well, all this depends on what a FeatureType is, semantically. The problem is that we have deviated from the ISO/GML definition to something more closely connected with an in-memory representation of a physical implementation. In some cases this is a workable surrogate, but what is the meaning of "ReType" for example.
I dont beleive we have a coherent definition of FeatureType once we lost the real one. The GeoAPI implementation is derived from the ISO definitions, and we should keep it clean to avoid inconsistencies and extra documentation burden if we choose to redefine it. I would suggest that we try to resolve the problem by cleaning up terminology and semantics. I'm not deeply in this code at the moment, so throwing up some ideas to see if it helps... FeatureType should be reserved for the target schema, which we may build an in-memory data model for, or potentially something that we can at least map queries and outut formatting to. Two FeatureTypes are equal if they have the same namespace and element name. If something has been allowed to declare FeatureTypes that have the same identifier but different content, this is logically a configuration error, and should be thrown at config load time. If a Features of a given FeatureType may be partially resolved to support queries or responses (attribute sets) this should not change the FeatureType. A "ReTypeFeatureReader" seems to exist purely to allow a partial resolution of Features from a persistence-layer derived FeatureType (something that should have a private namespace). Perhaps what RetypeFeatureReader _really_ is is a LazyFeatureReader, that resolves just some attributes. Then LazyFeatureReader.resolve(sourceFeatureType, attributemappingset) -> set of features of targetFeatureType. where attribute mappings match the attrinbutes of the source type to the target type. (in the current implementation this is crippled to "onto" mappings where the source and target names are equal, so mappings consist of just the attribute name, but fidMappers are closer to the general concept.) and we want to be able to chain this to resolve more attributes: maybe urm = LazyFeatureReader.getUnresolvedMappings(sourceFeatureType, attributemappingset) if ( urm not empty) LazyFeatureReader.resolve(sourceFeatureType, urm) This would allow incremental resolution. Of course, to optimise the set of attributes asked for in the initial transaction may be required for streaming large sets, but if the JDBC result set is maintained by the original source, and the lazy reading is chained properly, this should not be too problematic. It would allow the incremental resolution through queries ( resolve all the attributes I am not able to map into a datasource native query, then any I may need to apply filters in symbolisation (or mandatory elements demanded by the output schema + any asked for by a getFeaturesRequest). In any event, its up to the service call handler to marshall the set of attributes it needs. Granted, this may be a longer term solution -but maybe the short term solution is to realise we cant fix it with a bandaid, relax about it, implement a more brute-force strategy for now and be relaxed about it being inefficient until we fix it properly? Rob Andrea Aime wrote: > Hi all, > I have a few questions about a bug I've spotted in JDBC land. > > First thing is, why are there two ways to compare FeatureTypes for > equality? > The first one is FeatureType.equals(xxx), the second one is > DataUtilities.compare(ft1, ft2). > Some places use the first, others the second, maybe in the same > algorithm (bad idea...). > > Second, why DefaultAttributeType.equals(...) does not take into > account the restriction when evaluating equality? > > Finally, the bug. If I invoke getFeatureReader(FeatureType > requestedType, Filter filter, Transaction t) on a JDBC data store > and requestedType is a subset of the datastore's schema, I'm > guaranteed to get an exception from the ReTypeFeatureReader, > since the method builds a query that already extracts the > requested attributes but... there is a but in my opinion. > > What if the requested type had different restrictions on attributes? > Would it be ok to return a feature reader sporting a feature type > that's different (restrictions wise) from the one requested? > Depending on the application, the answer may well be no, because > the coder expects restrictions to operate on the returned features > as requested, no? > > Cheers > Andrea > > PS: PostgisDataStore overwrites the method inherited from > JDBC1DataStore, yet it does not seem to make any significant > change to it, seems more like an unmantained copy than something > with a purpose. > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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
