Justin Deoliveira wrote: > Hi all, > > I have made some changes to the jdbc module. I haven't committed yet and > was hoping that one ( or more :) ) of the other jdbc module maintainers > ( or anyone for that matter ) could perform a code review for me. Thanks Justin ... > Summary of changes: > > 1. Handling of simple xpath expressions. Now I know this sounds scary, > buts its not. As an example, when sql gets encoded, the xpath expression > "gml:name" fails, because of course the column has no notion of a > prefix. To fix is easy: > > Instead of doing the following: > > PropertyName name = ... > FeatureType featureType = .. > > AttributeType attributeType = type.getAttributeType( > name.getPropertyName() ) > > We do this: > > PropertyName name = ... > FeatureType featureType = .. > > AttributeType attributeType = name.evaluate( featureType ); > A nice elegant solution, before I call it complete can I ask how we can handle "@gml:fid" into a call to FidMapper (I do not need a solution just to make sure you have thought ahead to how to handle this case). +0 (changed to +1 when I see a comment on how "@fid can be handled in the future) > 2. Made it so that when attribute types are created, the "nullability" > of the database column is checked in order to determine a minOccurs > value, and if the type is nillable. > I like that, however to make this change complete can you document the FeatureFactory.create method (and FeatureType.create method) to reflect that minOccurs=0 should be handled as "null" (rather then an empty list).
+0 (changed to +1 when the creation code is documented to match) > 3. Setting the "userData" property of geometries that get created to be > the CRS of the corresponding attribute type. Now I know that this is a > *bad* way of doing this, and as a toolkit we can't rely on this loose > coupling between geometry and crs. However, there is no other clean > option until we abstract the jts geometry class behind the iso > interface, which is a huge job. > The only reason for this to come up is if the GeometryAttributeType.getCoordinateReferenceSystem() does not match the actual Geometry instances; the correlation between these two is an assumption plenty of code makes . I imagine the test case is your DataStore is changing it's CRS Geometry by Geometry, the other option besides user data, is to change your GeometryAttributeType to describe your data as each feature goes by ... an accurate but non pleasing answer. There is one counter example - render drags the first Geometry out of the collection (and checks user data!) and decides to trust this value of GeometryAttributeType.getCoordinateReferneceSystem(). This shows an utter lack of trust in datastore providers of course .... +1 because other alternatives are not available right now > And thats all folks :). > I think it is enough, 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
