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
