using long transactions would be pretty horrible :( long transactions should be avoided like the plague at all cost. Especially with certain databases (like Microsofts or Sybase variants)
i would do it how igors proposes. Have multiply rows for the same data with 1 row that is live and another row (with maybe the editting userid as data so that you know what to get the next time) The problem is can there be more then 1 person editting data? Are they editting there own set? or is there only 2 rows of the same data at 1 time? (live and edit) johan On 10/29/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > On 10/29/07, Tauren Mills <[EMAIL PROTECTED]> wrote: > > I have a wicket/hibernate/spring project that manages a set of live > > data. Users of the system view the live version of the data. > > Currently, administrative CRUD alters the live data as well. Changes > > by an admin are immediately reflected on the site to users. > > > > But a new set of features is going to require that administrators > > should be able to make updates and changes without affecting the live > > data. Once they are satisfied with the changes they have made, they > > can save/publish the "working data" to be "live data" on the site. > > > > The modification/editing of this data can take a fair amount of time, > > perhaps several days. Thus, I can't just put the working data into > > the session and then save it to the DB a few minutes later when the > > editing is done. The working data needs to be able to persist as well > > as the live data. > > > > Also, I'm reluctant to just make copies of all the data from the live > > version to the working version, because there are certain aspects of > > the live data that can be altered by the users. The users don't > > actually edit the basic data, but additional information is attached > > to the data as the user uses it. If the admin is editing data and it > > takes a few days, the copy of the data could get stale as users use > > it. Then I'd have data synchronization issues to deal with. > > > > I would google for patterns or techniques to deal with this type of > > situation, but I'm not sure what to even search for. Has anyone had > > to deal with anything similar? Any advice or suggestions? Or even > > keywords to search for? > > No real experience with this myself, but start with 'long transactions'? > > Eelco > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
