Hi Paolo,

  Thanks for your thoughts.  I'll defer to your experience in implementing
database plugins since I wasn't directly involved with coding the ArcSDE
plugin.  The problem I have with the DataStore ArcSDE driver is that it is
inherently multithreaded when you have more than one layer, so it seems to
bring out the worst in both the JUMP code and in the database system,
especially Oracle, which runs out of database connections much too easily.

  I agree with your statement about the caching mechanism.  I think the
class you are referring to is:
com.vividsolutions.jump.workbench.model.cache.CachingFeatureCollection.  I
like your idea of adding a "dirty" cache to hold edited records.  I'll give
some thought to how it might be done.

  I do have a little experience with using H2 on another project.  I can
report that I found it to be much faster in every way than Derby, especially
the embedded H2.  In general, it was a joy to work with.  It has an active
maintainer and good online documentation.

regards,
Larry

On Thu, Apr 23, 2009 at 4:27 AM, Paolo Rizzi <g...@oicom.com> wrote:

> > Thanks Stefan.  Also, as far as the best database base class to
> > consider, we have DataSource which loads the layer into memory, and
> > DataStore which doesn't but is read-only, and IMHO has problems with
> > multiple layers due to threading.  I guess, if I was starting the task
> > of implementing a new database driver, I would start with a DataSource
> > driver.  Then once I had that working I would implement a DataStore
> > driver.  Then I would consider how best to fix the DataStore model so
> > that it is more reliable and supports read/write.  There is also the
> > option of building a new database base class, but it would require a lot
> > of core mods to integrate into File->Open, etc.
> >
> > Larry
> Just my little 2c (as always I'm sorry of not contributing any code...).
>
> Regarding the summer work of H2 integration, if I recall well,
> Christopher talked about: "...very large TINs..." and that seems not
> well suited to be read in-memory.
> When I wrote my SISDB PostGIS/Oracle plugin, back in 2006, I looked at
> the code for both DataSource and DataStore and found that the DataStore
> design was _much_ more clean and carefully thought out than DataSource.
> So I decided to follow the DataStore design and never regretted it,
> infact the plugin always worked like a charme, even on machines with low
> memory available.
> I never had problems with multiple layers, but it's maybe because I had
> to use a separate reading thread inside the plugin...
>
> Reagarding the addition of writing capabilities to the DataStore
> interface, what is actually needed is something inside the core itself.
> I never studied the code, but I believe there's a "caching" mechanism of
> some sort already in place in OJ, and I think it works upon the current
> view, so if it needs data outside of it, the cache requests it to the
> DataStore. I also imagine that upon some condition (memory occupation)
> this cache simply discards out-of-view features.
>
> To implement writing, it is necessary that dirty features
> (modified/inserted/deleted) are not discarded, but are kept or copied to
> a "dirty" cache. When the user eventually decide to commit, the dirty
> features are to be passed back to the DataStore along with their
> corresponding operation (Modify/Insert/Delete).
>
> To add writing it is not required to modify the DataStore interface at
> all, so that existing plugin will continue to work.
> A new DataStoreWriter interface may be created for this purpose and an
> "instanceof", or something like that, can be used to dinamically cast a
> plugin to be a writer, only if it actually implements that interface. Or
> even a DataStoreWriterProvider interface maybe defined with a single
> method DataStoreWriter getWriter(), so that delegation can be used.
>
> Obviously DB tables are required to have a Primary Key to be editable
> and also some sort of conflict resolution mechanism, or at least
> something to inform the user of what has happened, but these two
> requirements both exists even if following the DataSource paradigm.
>
> Bye
> Paolo
>
>
> >
> > On Wed, Apr 22, 2009 at 2:51 PM, Stefan Steiniger <sst...@geo.uzh.ch
> > <mailto:sst...@geo.uzh.ch>> wrote:
> >
> >     +1
> >
> >     I was going to ask by the end of the week if Landon tested it and if
> we
> >     can add the method. Basically I just trust you on that (having way
> more
> >     developer experience than I have).
> >
> >     sorry that databases are not my area if expertise - although I may
> know
> >     some very few things about it
> >
> >     stefan
> >
> >     Larry Becker wrote:
> >      > To maximize the use of Christopher's time this summer integrating
> H2
> >      > spatial, we should ensure we have the database code
> >     infrastructure ready
> >      > so he can focus on the actual problem.
> >      >
> >      > So the first step would be consideration of my proposed mod to
> >      > BasicFeature to add an isModified() method.  I have been testing
> >     this in
> >      > SkyJUMP and it seems to work as I expected.  If you recall, this
> >     basic
> >      > support is needed to make it possible to know what database
> >     records to
> >      > update, since (for large dbs) you can't realistically expect to
> write
> >      > the whole database table each time you change a record.  Other
> >     methods
> >      > are required to track deletions, and perhaps additions.
> >      >
> >      > As far as other database support enhancements go, I would like to
> >     hear
> >      > from Martin.  This would seem to be something to which he might
> have
> >      > given some thought.
> >      >
> >      > regards,
> >      > Larry
> >      >
> >      > --
> >      > http://amusingprogrammer.blogspot.com/
> >      >
> >      >
> >      >
> >
> ------------------------------------------------------------------------
> >      >
> >      >
> >
> ------------------------------------------------------------------------------
> >      > Stay on top of everything new and different, both inside and
> >      > around Java (TM) technology - register by April 22, and save
> >      > $200 on the JavaOne (SM) conference, June 2-5, 2009, San
> Francisco.
> >      > 300 plus technical and hands-on sessions. Register today.
> >      > Use priority code J9JMT32. http://p.sf.net/sfu/p
> >      >
> >      >
> >      >
> >
> ------------------------------------------------------------------------
> >      >
> >      > _______________________________________________
> >      > Jump-pilot-devel mailing list
> >      > Jump-pilot-devel@lists.sourceforge.net
> >     <mailto:Jump-pilot-devel@lists.sourceforge.net>
> >      > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >
> >
> ------------------------------------------------------------------------------
> >     Stay on top of everything new and different, both inside and
> >     around Java (TM) technology - register by April 22, and save
> >     $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> >     300 plus technical and hands-on sessions. Register today.
> >     Use priority code J9JMT32. http://p.sf.net/sfu/p
> >     _______________________________________________
> >     Jump-pilot-devel mailing list
> >     Jump-pilot-devel@lists.sourceforge.net
> >     <mailto:Jump-pilot-devel@lists.sourceforge.net>
> >     https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >
> >
> >
> >
> > --
> > http://amusingprogrammer.blogspot.com/
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> ------------------------------------------------------------------------------
> > Stay on top of everything new and different, both inside and
> > around Java (TM) technology - register by April 22, and save
> > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> > 300 plus technical and hands-on sessions. Register today.
> > Use priority code J9JMT32. http://p.sf.net/sfu/p
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>



-- 
http://amusingprogrammer.blogspot.com/
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Reply via email to