SQLDialect.encodeGeometryEnvelope needs to pass in the descriptor and the connection

Andrea Aime added a comment - 24/Oct/08 9:54 AM Attaching partial patch, to really work this needs more changes

Andrea Aime added a comment - 24/Oct/08 10:00 AM Justin, I realized only after partial coding that just modifying the method won't work. When SDO_TUNE is used, the query must be (for a generic set of various geometries): {code} select SDO_TUNE(tableName, geom1) from dual {code} That "from dual" breaks the current code, which instead uses {{from tableName}}. But the fun does not end here, in the case of Oracle, SDO_TUNE can be used only for flat, non geodetic geometries. This means that it's not possible, in general, to extract the bounds of multiple geom columns in one shot as the datastore is doing now, because the SDO_AGGR queries are instead expressed as: {code} select SDO_AGGR_MBR(geom) from tableName {code} Ouch... it seems to me Oracle could enjoy a custom datastore implementation that overrides the way bounds are computed? This would mean removing the "final" modifier from JDBCDataStore and adding in the comments that subclassing the JDBCDataStore class should be considered an extreme measure. Oh, it's quite likely I'll also have to subclass JDBCDataStore in order to make versioning work with the new postgis datastore (I need to override the way primary keys are handled).

Justin Deoliveira added a comment - 26/Oct/08 1:06 PM Hmmm... interesting. Well i would like to avoid subclassing at ALL costs. What I would rather do is perhaps add some sort of capabilities notion (or some flag) to the dialect. In which the datastore can check the flag and if set the datastore completely delegates to the dialect for computing bounds and does not try to do any of the work of building the query.

Andrea Aime added a comment - 09/Dec/08 5:17 AM Oh, I could go for that, it's trading a complexity in the code for one in the sql dialect, whose number of methods is ever growing.... personally I'd prefer to have just one method and have the default sql dialect to do the work done by the datastore now instead of having two more methods (caps and the full encode one) but I'm open to both options

Andrea Aime added a comment - 23/Dec/08 12:36 PM Ok, so let's define which methods need to be added to SQLDialect. What about: boolean useVendorBoundsQuery(SimpleFeatureType featureType, Filter filter); ReferencedEnvelope getBounds(SimpleFeatureType featureType, Filter filter, Connection cx); The first can be used to avoid replicating all the code in the cases in which SDO_TUNE cannot be used anyways (when Filter is not INCLUDE) and the second, well, basically replaces the one from JDBCDataStore when the dialect needs it.

Justin Deoliveira added a comment - 28/Dec/08 12:40 PM Sounds good to me. Can we call the methods useNativeBounds(...) and getNativeBounds(...), i prefer the word native over vendor and having them both contain "native" more clearly defines they are related.