Chris Holmes wrote:
Hey Jody, I'm looking to do prepared statements in PostGIS, but have a couple questions.
It looks like you just call:
String sql = makeInsertSql(current);
statement = conn.prepareStatement( sql );Just to confirm, the docs seem to say that you don't need to have '?' things in your sql statement, so basically this code says to me that you just use the SQL statement with values, but since you're using the compiled statement it will it ignore them. Is that right?
Second, this doInsert is just called on one feature, so it doesn't appear to me to gain any of the supposed big win of using prepared statements:
This is all true, we should cache the prepared statement, remember this was only done to make doing additional geometry types possible at all. The SQL writer only did like three of them, this will do them all.
I have not started an optimization run yet, I have been away for most of the week. Today I am laying the foundation, and want to be ready for when Justin has his data. That way I get a good bug reports.
'Note: This method is optimized for handling parametric SQL statements that benefit from precompilation. If the driver supports precompilation, the method prepareStatement will send the statement to the database for precompilation. Some drivers may not support precompilation. In this case, the statement may not be sent to the database until the PreparedStatement object is executed.'
This seems to imply to me that if you call prepareStatement each time, then it has to create a new one. That we'd get the pre-compilation if we had addFeatures(features) prepare the statement, and then each doInsert would use that same prepared statement...
Or is the system smart about caching the prepared statements, and it calls them if they've already been compiled?
Or have you not tested when trying to insert a number of features in one insert statement?
You are simply wishing I was ahead on this one.
Incidentally, my previous work here in SA has been on the project planning side - so I have not had much time for geotools beyond PMC volunteer work. Now that I am moving into a coding phase I should be of more assistance.
Related to this Chris I would like it if we could sort through some community issues. I am still concerned that the geotools projects are not set up to do this kind of thing well. We tend to focus on the need to document and provide training material. At the other end of the spectrum we need to help those who do figure things out feed patches back into the community. As an example each commercial project I know of has a low rate of providing feedback to the community, admittedly this gap is at module maintainer level. Perhaps we could find a way to aid in communication?
As an example uDig is keeping the following forked code alive:
- svn.geotools.org/udig/trunk/gt
- http://svn.geotools.org/udig/trunk/plugins/net.refractions.udig.catalog.oracle/
- http://svn.geotools.org/udig/trunk/plugins/net.refractions.udig.catalog.postgis/
- http://svn.geotools.org/udig/trunk/plugins/net.refractions.udig.catalog.hsql/
- http://svn.geotools.org/udig/trunk/plugins/net.refractions.udig.catalog.db2/
In each case we have been forced to fork some code to accomplish what was needed, and due to geotools overhead only every manage to bring back say 20% (what we remember as good). Does GeoServer still maintain some forked geotools code? Or only the geoserver brances such as WCS? One thing that we do in uDig that is helpful is the community svn access, you have a similar situation with the number of branches in GeoServer. At least by providing developers with their own branch we can notice where the activity is taking place and go hunting for it after the fact.
Over the next year I would like to see us reduce the overhead involved in providing patches so we can better make use of those working on commercial projects. This situation is not unique to geotools: GeoServer and uDig also have some great improvements that don't always find there way home.
Cheers,
Jody
Chris
Jody Garnett wrote:
Um dave the method was from OracleFeatureWrtier (well actually JDBCFeatureWriter) and was the original horrible hack left over from the DataSource api.
I have updated it to use prepared statements, SDO class still I have added the dependency on JTS1.7, but still need to pick up jtsio dependency.
Jody
That method will take care of it for you, notice MultiLineString is a subclass of Geometry
Cheers,
DavidOn 3/14/06, *Oliver Loe* <seedollar@anonymised.com <mailto:seedollar@anonymised.com>> wrote:
Hi
I'm trying to encode MultiLineString geometries to be inserted
into oracle. I found this method in SQLEncodeOracle:public static String toSDOGeom(Geometry geometry, int srid) {
if (Point.class.isAssignableFrom(geometry.getClass())) {
return toSDOGeom((Point) geometry, srid);
} else if
(LineString.class.isAssignableFrom(geometry.getClass())) {
return toSDOGeom((LineString) geometry, srid);
} else if
(Polygon.class.isAssignableFrom(geometry.getClass())) {
return toSDOGeom((Polygon) geometry, srid);
} else {
LOGGER.warning("Got a literal geometry that I can't
handle: "
+ geometry.getClass().getName());return "";
}
}It does not cater for MultiLineString objects. How can I get
around this? Is there a fix for it?
Oliver-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
geotools-devel List Signup and Options
