Rob Atkinson ha scritto: > Fantastic news. > > I'll look to get the geometryless module into supported status around > this - my only blocker at the moment is the lack of the functionality > currently wrapped in sql-datastore (under 2.4 > ./unsupported/community-schemas/sql-datastore) in JDBC.
I did look at the geometryless module some time ago and I was quite surprised to see it put in the same class geoemtryless support along with mapping... imho they should be separated. Most JDBC based datastores nowadays do support tables without a geometry in (thought probably the new one hasn't been checked for this specific case, opened a jira to make sure we don't forget http://jira.codehaus.org/browse/GEOT-2002). The issue of mapping 4 fields into a bbox or 2 into a point is imho unrelated to sql and should be handled in a separate wrapper datastore that only concerns into mapping a geometryless feature type into another that has geometries. A few examples of geometryless data sources out of the jdbc land: * csv/xms/generic flat table files * a remote geometryless wfs type I would better see a generic mapping datastore using generic mapping strategies, each strategy could be something something like (thinking as I write): - set of attributes in input - set of attributes in output - invertible flag (is it possible to go from outputs to inputs)? - forward and backwards data transformation - forward and backwards filter transformation (when possible) This could handle everything from simple renames to computations to lumping togheter a set of fields to build a new one. Ok, here I'm going way off topic, if you want to discuss this further please let's open a new mail thread. > Gabriel did > this work and I extended it to provide a little bit of dialect-flag > driven handling of different date literal handling. My hope is that > both of these extensions will be rendered superfluous by the new > prepared statement handling design and dialect handling. Certainly I > only need the dialect handling for Oracle, so I'd strongly suggest a > good set of unit tests around date, time, timezones. The datastore structure provides a set of abstract conformance tests that specific dialects implement in order to check their conformance for a specific api or a specific topic. For example, I just recently added two new base classes for testing geometry type binding and spatial filters. You're more than welcomed to add date/time handling tests as well. > WARNING: There is a flag that Oracle can run under to determine the > datatype of timestamps returned by JDBC - you need to handle both > potential settings of this flag. [ -Doracle.jdbc.J2EE13Compliant=true] What is this all about? A VM flag is scary, if this is useful, is there any way to set it in the connection string instead? Hum... yeah, it seems so: http://www.oracle.com/technology/tech/java/sqlj_jdbc/htdocs/jdbc_faq.htm thought the document does not make > There is also a set of extensions under jdbc-regfunc which allow > specific database functions to be exposed. Due to vacations and the usual ton of stuff I have to attend to I did not manage to follow this one. Is this about filters? > IMHO These capabilities would be of general interest - there's many a > potential JDBC datastore where you will want the ability to select > specific columns, or do some joins across lookup tables. We've been > put off proposing them as fixes to JDBC pending Jody's view that H2 > work will supercede it. This is native JDBC functionality and I would indeed like to see this added to the JDBCDataStore, that is, stuff like: - way to handle joins - way to register a random sql query as a new (read only) feature type, eventually with parameters (think a dynamic query that extracts certain rows based on the current user, we could feed that thru the Query hints) > Gabriel is familiar with the code, so would be the best person to > comment specifically, but if people want us to try to roll it in and > create patches and proposal then we can schedule that - but IMHO it > would be best if it were considered up front and the capabilities > supported without the need for a patch. If we could do planning with lots of time ahead yes, but our reality is different and does not allow for this kind of planning. The first cut of the H2 datastore was for the wfs 1.1 + xlink work, and had certain time limitations. This one is about adding Oracle support and has to be done within 2-3 weeks tops. If you're lucky to have the necessary planning time, join, make proposals, and we'll try to find the time to discuss them. Cheers Andrea ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
