Andrea Aime wrote: > 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). > Andrea, everything in DataUtilities were tools needed in the heat of the moment to get the job done. It could be that FeatureType.equals( xxx ) was eventually "fixed" and DataUtilities.compare( ft1, ft2 ) is no longer needed.
It is also likely that DataUtilities method is doing something a little specific needed for GeoServer (all these methods date from early GeoServer work). > Some places use the first, others the second, maybe in the same algorithm > (bad idea...). > Gah. Correct: use FeatureType.equals( xxx ), with the understanding that the FM may change the scope of what a FeatureType is and upset code. Safe: use DataUtilities.compare as it is a method we can ensure works with the new feature model (say only checking the data compatibility of the two feature types) > Second, why DefaultAttributeType.equals(...) does not take into account the > restriction when evaluating equality? > Restrictions were added by David Zwieres and Chris Holmes, I suspect they just missed it. > 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. > Okay I understand that .. I would hope that ReTypeFeatureReader is not checking things carefully and just calling create( Object[]) using your provided FeatureType :-( > 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? > Depends on your view of valid vs invalid data. Should invalid data exist? Should we allow it to be created? Currently we do not allow invalid data to be created (let alone handled), the FeatureType represents a *contract* or assurance to consumers of the data (say an XMLTransform) that only valid data will be provided. Difficulty is that invalid data does in fact exist, and as such we should be able to model it (even if just to clean it up). Answer: Make ReTypeFeatureReader skip over any content that is "invalid" against those restrictions, and log the warnings. This should already happen as part of that FeatureType.create( Object[] ) step I guess. May need to check to see if the reader gives up at the first failure, or keeps trying ... > Depending on the application, the answer may well be no, because > the coder expects restrictions to operate on the returned features > as requested, no? > See above, can we use the restrictions as an additional filter on the content (even if just done post processing as part of the ReTypeFeatureReader). Jody > 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. > I noticed that as well, it *did* make a change, but had not shared it with others (think it added event notification or something?). I ended up taking the change up to JDBC1DataStore, but without online tests I feared to do more then that. 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 > ------------------------------------------------------------------------- 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
