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,
David
On 3/14/06, *Oliver Loe* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
https://lists.sourceforge.net/lists/listinfo/geotools-devel
-------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/geotools-devel
