Re: [Geotools-devel] Some questions about JDBC DataStore

[<ch...@op...>]

> >>In these days I am trying to complete the PostgisDataStore to use
> >
> > Postgis  with geotools.
> >
> >>Basically, what I'm going to add is:
> >>* support for wbk4j while reading (already done)
> >
> > Excellent!  My procrastination has finally paid off...  I've been
> > meaning to implement that for far too long now.  I actually started
> it
> > awhile ago, but never quite finished, there is my attempts at
> starting
> > on a branch.  Though even if you didn't find that stuff it's really
> not
> > too hard of a problem.  I'm hoping you just made a wkb
> attributeReader?
>
> In fact we just did a test with some simple code, and it took me half
> an
> hour to make it perform just like the wkt code... no, I'm not
> kidding.
> Attached you'll find a simple but working code that reads the data
> from
> a postgis table using wkb and a single query. The initial version
> here
> took 5 seconds using wkt and 30 seconds using the original version of
> the
> wkb due to the conversion between the string hex encoding of the wkb
> and
> the real binary version. I've optimized the code and now it also
> takes 5
> seconds to read the wkb... (oh, the dataset in shapefile format is
> around
> 10 MB).
Cool.


> Using a binary cursor as suggested by the wkb4j author is not a
> solution
> to me since it would require two queries, one to read the geometry,
> and
> one to read the attributes, and I guess it would take even more time,
> also,
> there is a possibility that between the first and second query
> another
> user modifies the data (by inserting/deleting/updating a record of
> that table),
> to avoid that we could pump up the queries to higher isolation level
> and close
> them into a transaction, but first, I don't know if Postgres supports
> it, second,
> requiring an isolation level higher than "read commited" usually
> incurs in
> sensible performance penalties... don't know how postgres multiple
> versioning
> can affect that situation thought.
I agree, I was not going to implement it with the binary cursor either. 
I tried experiments with it and concluded like you that using the
string hex would probably be better.  One thing the postgis guys
suggested is to use the binary and cast all the others to strings (like
with postgis calls str:: or something).  The one thing with that that I
couldn't work around was that then jdbc returned everything as a
string, it didn't do the nice object construction for us (though it
should be possible, since everything in the postgres jdbc driver is a
string anyways, I'm just not sure exactly how it does it).

> Oh, setting the fetch size on the prepared statement is required
> since it's
> the only way to make it load data as its requested instead of reading
> the
> whole resultset into memory.
Yeah, that and setting autocommit to false, I'm pretty sure.  I'm
working on rolling these (or at least the fetch size false) into
jdbcdatastore.

Chris

>
> Best regards
> Andrea aime
>
>




----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/