[Geotools-devel] SDE complex-features port to trunk

[Saul F. <Sau...@st...>]

Hey gabriel,

I had a chance to go through your SDE datastore code on complex 
features, and I'm really impressed.  Lots of great ideas, and I really 
like the FIDReader stuff to support a more general approach to fetching 
FIDs from sde rows.

I have a couple of comments, which I'll try to put in decreasing order 
of importance.

1)  The current FIDReader solves the problem of how to get a good FID 
out of a feature quite nicely.  However, FIDReader isn't used in the 
SQLEncoderSDE class at all, so while your FID might be excellently 
*returned*, FID filters won't generally query the FID column correctly. 
  Did I overlook some logic in the code somewhere on that one?


2)  The work on "inproccess" sde views is really cool.  Thinking about 
how to return FIDs on a view is tough...but how about instead of just 
punting the question (FIDReader.NULL_READER) one created a "composite" 
fid?  Take the FIDs from each of the underlying tables, and put a ":" or 
"-" inbetween them all.  the SQLEncoderSDE part of that (where you break 
out the "composite" FID back into the query) would be a bit tricky, I 
suppose.


3)  There have been a few little patches to the ArcSDE datastore code 
since complex-features went in.  Like some optimizations to the common 
case of getting the layer extent for the whole layer (getLayerExtent 
with null query) and handling dead connections (like if the SeQuery 
object poops out in the middle of a query), so we should make sure those 
get merged into the port.


4)  Would you consider back-porting from trunk to 2.3.x when it's on trunk?

5)  Doesn't this strategy do the opposite of what we were discussing 
yesterday?  I mean, if the OBJECTID column is the sde-managed row-id 
column, doesn't this implementation return OBJECTID as an attribute 
*and* as the FID?


I'm really excited to see this stuff make it to trunk (and hopefully 2.3.x!)

--saul