It does seem like having 'dump entire catalog' functionality would be useful (for migrating between different persistence mechanisms) so (for another compromises solution) maybe we could just have a button to download/snapshot the catalog and leave it up to the admin to handle backup policy.
-David Andrea Aime wrote: > Justin Deoliveira ha scritto: >> >>> I share the same concern. We do want to save along the way since we >>> cannot be sure there will be a clean shutdown (jvm segfaults anybody?), >>> so eventually on shutdown we'd just be saving whatever was already >>> saved the last time the config did change? >> >> Yeah its a darned if you do darned if you don't sort of thing. On the >> one hand saving when the user decides to from the ui or at shutdown >> allows the ability to rollback or revert changes. Auto-saving >> everytime something gets modified removes the ability to do that but >> prevents loss of data when the system crashes. >> >> I wonder if we could introduce the idea of a session (and i dont >> really mean page session here) to get best of both worlds. Basically >> instead of saving directly to persistence we save to a session. The >> session is persisted immediately to disk whenever a change occurs. If >> the user decides to save changes from the session are persisted. In >> the event of a jvm crash GeoServer could detect that the session was >> not saved and restore it so no work is lossed. Not sure if it will >> work or its worth the effort, just a crazy idea. > > So basically instead of having the DTO on top of catalog, we have their > cousins below it? ;) (ok, I understand you can store stuff in whatever > way you want, not necessarily objects). > > For what it's worth, I'd just go to the direct save route. People > are working directly against databases with a lot of software, and > none of it give you the "undo/redo" ability of a desktop app without > much complaints. > > Wait... what did I just say? Undo/redo huh? We _could_ in fact store > on the disk a list of commands that morph the catalog and allow > people to actually undo their changes... that would be a first for > server side apps. And of course, it assumes a single admin model, or > else, we'd have to mark changes with the user that performed them > (with the new security subsystem any user can have the ROLE_ADMNISTRATOR > role). > > Cheers > Andrea > > !DSPAM:4040,486244e433951637810514! > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
