Jody Garnett ha scritto: > Hi Vitali - >> I have implemented on the top of GeoTools DataStore/Feature API and existing >> Oracle plugin a new OracleDataStore with a concept of Feature binding >> (something similar to Hibernate but much more simple and narrow).
Nice. Do you have some code to share for a review? Talking is nice, seeing the code is better (for me at least). > I think I understand what you are saying: sunburned surveyor and I were > kicking a similar idea around on blog pages >> Briefly to say, we needed direct feature access to Oracle Spatial with good >> performance using prepared statements with geometries being passed as STRUCT >> objects (prepared objects), with capabilities and powerful customization of >> the OracleDataStore implementation, with taking into account a nature and >> differences of JDBC against standard GeoTools reader/writer architecture. Vitali, I've made quite a bit of patches on the current Oracle data store during the current week. Since you have re-implemented, maybe you have already fixed those, but I'd suggest you have a look at jira recently closed issues anyways. > For sure. To be clear the result better darn well not be a > reader/writer. It should be a FeatureCollection (over top of a result > set random access or forward only as you see fit). Sigh... FeatureCollection is a broken API, no matter how you sponsor it :) Accessing something that can legitimately throw IOExceptions, needs scarse resources with an API that has no such concepts is bad. I know you think otherwise, and it's fine, but I'm a coder, and as a coder, I tell you that API promotes bad approaches to data access. The method general semantics are fine, the idea of returning a plain Iterator is silly, the lack of "throws IOException" on each method is so bad I won't even start to comment on it. FeatureReader/Writer are very limited, aren't that good for JDBC data access, but they state clearly in your face that you're doing I/O and that you have to close the darn resources after you have done. I value that more than the inherent limitations in the class semantics (which are clearly inferior to the collection ones). >> The user API is the same: DataStore/FeatureSource/FeatureStore. But internal >> implementation gets rid of FeatureWriter approach that is so inconvenient >> for JDBC and uses a concept of JDBCOperation interface instead of writers. >> > Okay you are now on exactly the same page as justin and myself. If you > check out H2 you will find that FeatureReader/FeatureWriter is treated > as a legacy API that is wrapped over top of a FeatueColleciton iterator. >> There are several operation interfaces: >> SelectJDBCOperation >> UpdateJDBCOperation >> DeleteJDBCOperation >> InsertJDBCOpearation >> MetaDataJDBCOperation >> CustomJDBCOpearation >> >> There is factory interface JDBCOperationFactory that creates instances >> of underlying operation interfaces and DataStore contains a factory (get/set >> methods). So, all real JDBC stuff is moved to the implementation of the >> factory and its set of operations for the particular database (like Oracle). >> > I see - interesting. Justin also was forcing me into this approach - he > was isolating all JDBC stuff into one class. My intention was to isolate > everything into three implementations of FeatureCollection (one > representing the entire table, one representing wrapped over a result > set, and one just used to hold the where clause. Sounds kinda artificial to me.... I like better Vitali approach (it feels better from a database coding point of view), but I'd like to see the implementation first. Prepared statement setup is similar in all DML operations, update and insert have further similarities, and so on. > If possible try and look at hibernate UseType - which can gobble up more > than one column when creating compound objects (easy example is Range). UserType is nice. But remember it works because you have a: * fixed bean model and * you explicitly declare the mappings In our case, Feature is totally generic. We would have to augment the JDCBDataStore interface to allow for mapping specification, something like: for feature type "X", apply UserType "MyUT" on columns "C1,C2,C3". (I'm not saying it's a bad idea, just that it's more work). >> Etc... Here are just some words to outline the situation. It is better to >> see the code and understand these concepts that from my point of view make a >> progress in GeoTools JDBC datastore implementation process for different >> databases and application-dependent specific customization on the top of >> default implementations. >> >> We use this new OracleDataStore implementation in a production project for >> Oracle 10g/9.0 with UDIG platform based application. >> > Sweet; okay I did not understand you had written this puppy already. >> The datastore is able to INSERT/UPDATE/DELETE/SELECT any type of JTS >> geometry model through prepared objects converting. >> >> Right now the source code is not well commented while the development was in >> a hurry. But I think we may share this stuff for the community development >> right now and improve necessary places to align the architecture with lot of >> improvements at the GeoAPI/GeoTools things. >> > For sure - grab an unsupported module and get the code out there for > review. There are some hoops to jump through to roll it into GeoTools > (headers, test coverage, user docs etc...). Well, discussion and whatnot too. But it's ok, as long as it's a separate module, we can keep both around (since we did not talk about read side performance, filter encoding capabilities and so on. A nice architecture is a plus, but for Geoserver I need something that is no less than the old datastore _from the user point of view_ as opposed to the programmer point of view). Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
