Using H2 as the base storage/retrieval module for OJ is my end goal, and for that H2 embedded is without a doubt the best choice. I think, though, that I will program everything to use automatic mixed mode: the first program to open the database gets it in embedded mode then it opens a server so that other programs can access the database using TCP. The standard use case where embedded mode would be assumed is opening a local, unshared file, which would work as assumed when using automatic mixed mode while still gracefully allowing other use cases.
--Christopher --- On Thu, 5/28/09, Stefan Steiniger <sst...@geo.uzh.ch> wrote: > From: Stefan Steiniger <sst...@geo.uzh.ch> > Subject: Re: [JPP-Devel] UI direction for native database integration > To: "OpenJump develop and use" <jump-pilot-devel@lists.sourceforge.net> > Date: Thursday, May 28, 2009, 2:17 PM > well... the original (and existing) > idea was to use H2 embedded to > overcome our memory dependence. > > stefan > > Larry Becker wrote: > > Another factor to consider is embedded H2 vs server > H2. Embedded is > > faster so it should probably be used for option 1 and > default use. > > Personally, I'm more excited about the ability to > collaborate with other > > users using server H2. The connection strings > control which is used so > > there is probably nothing to program. Just > include the h2 jar in lib to > > get embedded and trust the user to install h2 server. > > > > Larry > > > > > > On 5/27/09, *Michaël Michaud* <michael.mich...@free.fr > > > <mailto:michael.mich...@free.fr>> > wrote: > > > > Hi, > > > > I second Paolo in most of his > comments : > > > > Option 1 would be great for > data/project exchange. Including project > > information (layer styles) in > the database would be great also, but it > > may be difficult to manage > style definitions in both xml files and > > database. About references to > external data, I can see pros (more > > freedom about how and where to > store data) and cons (may be difficult to > > know what to transfer if you > want to move the entire project). > > > > Option 2 : agree with > Paolo, just a different UI to access database > > table (nice but not as > important as 1 and 3). > > > > Option 3 : probably the best > short term goal. But again agree with > > Paolo. Main questions are not > related to UI but to the datastore access > > capabilities, writing access, > access to huge tables, transaction > > management...But I'm not an > expert in that domain and I'm sure that > > Larry's propositions to track > feature modifications will make some of > > these things possible. > > > > Very exciting propositions > indeed. > > > > Michaël > > > > > > Paolo Rizzi a écrit : > > > Option 1 is intriguing, > because it would be a very good mean of > > > exchanging geo data, a single > file with everything inside, very > > good!!! > > > Maybe an ibrid solution were > the project is itself store inside > > the H2 > > > database, while each Layer > can be internal or external would be even > > > better. Also you could store > inside the H2 project both a Layer > > data and > > > a reference to its original > provenience, to support some form of > > > disconnected editing, but > this is maybe too sophysticated... > > > > > > Option number 2 would be just > a shortcut upon number 3, a > > different UI > > > to select a database table, > so it doesn't seems interesting. > > > > > > Option number 3 is good > enough, but remember that DataStores are > > > read-only, so this would be a > very good time to extend them to > > support > > > writing. > > > There were a couple of > threads a few weeks ago about this and about > > > tracking modifications inside > features. > > > The main goal was to be able > to incrementally commit changes to a > > DataStore. > > > A simpler solution, but good > enough for a start, would be to only > > > support complete Layer write > inside a DataStore. > > > That is, always re-write the > entire Layer each time, just like > > you would > > > do with a shape file. > > > Problem is with DataStores > you don't have the entire Layer in memory. > > > So, to support this complete > re-write, you should read the entire > > Layer > > > in memory, truncate the > database table and recreate it. But this is > > > quite a dangerous solution, > because if OJ crashes for any reason, you > > > loose your database data, > unless you made good use of RDBMS > > transactions. > > > Another solution would be to > create a new table inside the database > > > where you can merge the old > table with the modified features you > > have in > > > memory, but this would not be > very different from doing > > incremental writes. > > > Summing it up, it seems that > supporting incremental writes for > > DataStore > > > is indeed needed anyway. > > > > > > Bye > > > Paolo > > > > > > > > > > > >> What direction(s) does > the community want me to go toward with > > regards to integrating the H2 > database into OpenJUMP? > > >> > > >> Here's some initial > options I've come up with: > > >> > > >> 1) Project as a > database: > > >> When creating or saving a > new project, you could select to make > > it a database project. Then > all layers that are created are > > automatically saved into the > database and when external layers are > > opened, the option for copying > them into the database or leaving > > them external is given. To > open a database project, simply open the > > associated H2 database. > > >> With this option, all > project data can be stored in one file > > that can easily be moved > around. > > >> > > >> 2) Database as a file > folder: > > >> This is in the ArcMap > style where the open file menu and save > > layer menus treats the > database as simply another folder that you > > can navigate into and select > individual files. > > >> > > >> 3 Database as a Data > Store Layer: > > >> Use that Open Data Store > and Connection Manager dialogues to > > manage opening and saving of > layers. This would probably be the > > simplest to code with the > least amount of core modification (if > > any), but I'm not sure that it > would be as intuitive and invisible > > as it could be. > > >> > > >> Any comments or other > suggestions? > > >> > > >> --Christopher > > >> > > >> > > >> > > >> > > >> > > > ------------------------------------------------------------------------------ > > >> Register Now for > Creativity and Technology (CaT), June 3rd, NYC. CaT > > >> is a gathering of > tech-side developers & brand creativity > > professionals. Meet > > >> the minds behind Google > Creative Lab, Visual Complexity, > > Processing, & > > >> iPhoneDevCamp as they > present alongside digital heavyweights > > like Barbarian > > >> Group, R/GA, & Big > Spaceship. http://p.sf.net/sfu/creativitycat-com > > >> > _______________________________________________ > > >> 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 > > >> > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Register Now for Creativity > and Technology (CaT), June 3rd, NYC. CaT > > > is a gathering of tech-side > developers & brand creativity > > professionals. Meet > > > the minds behind Google > Creative Lab, Visual Complexity, > > Processing, & > > > iPhoneDevCamp as they present > alongside digital heavyweights like > > Barbarian > > > Group, R/GA, & Big > Spaceship. http://p.sf.net/sfu/creativitycat-com > > > > _______________________________________________ > > > 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 > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > Register Now for Creativity > and Technology (CaT), June 3rd, NYC. CaT > > is a gathering of tech-side > developers & brand creativity > > professionals. Meet > > the minds behind Google > Creative Lab, Visual Complexity, Processing, & > > iPhoneDevCamp as they present > alongside digital heavyweights like > > Barbarian > > Group, R/GA, & Big > Spaceship. http://p.sf.net/sfu/creativitycat-com > > > _______________________________________________ > > Jump-pilot-devel mailing list > > jump-pilot-de...@lists.sourceforge.net > > <mailto:Jump-pilot-devel@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > > > > -- > > Larry Becker > > Integrated Systems Analysts, Inc. > > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------------ > > Register Now for Creativity and Technology (CaT), June > 3rd, NYC. CaT > > is a gathering of tech-side developers & brand > creativity professionals. Meet > > the minds behind Google Creative Lab, Visual > Complexity, Processing, & > > iPhoneDevCamp as they present alongside digital > heavyweights like Barbarian > > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, > NYC. CaT > is a gathering of tech-side developers & brand > creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, > Processing, & > iPhoneDevCamp as they present alongside digital > heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
