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-devel@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
