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