Me too. we have an application underway which will require some offline operation. While it won't have masses of conflicting stuff, unique key generation would be nice.
However, I expect the offline abilities to be expanded in future, which would make things more messy :) Thanks, Rob :) Quoting Jason Pyeron <[EMAIL PROTECTED]>: > ditto. > > we have two (2) applications under way right now, which we want to do > something similar. > > 1) n locations connected by a 90% up slow link, these locations need > access to each others information, and not to conflict. > > 2) a port of bugzilla, which will allow offline entry/submission > > -Jason Pyeron > > On Sun, 30 Nov 2003, Colin Kilburn wrote: > > > Gustavo, > > > > I expect to have a project soon that will require some replication, > although perhaps with differing requirements, but I'm sure there'll be some > overlap in requirements as well as challenges. At minimum I'd be interested > in discussing issues and approaches in this arena "soon" (I'm currently very > tied up trying to finish another project.) > > > > What results from these efforts (or at least parts of them) may be generic > enough to be useful to others. Anyone else? > > > > Colin Kilburn > > > > [EMAIL PROTECTED] wrote: > > > > >Hi all, > > > > > >We’ve being using OJB for a while and we do like it. > > >While we depart from the old paradigm (delegating the "important" stuff to > > > >the RDBMS) and we delegate OJB the real work, some > > >opportunities/challenges come to our mind. > > >And since data/object replication is one of those opportunities, we would > > > >like to address in a new project. We believe OJB is ready for a job like > > >this. > > > > > >Let’s say we have some data collection apps running in notebooks > offsite. > > >Thanks to OJB, the app runs on almost any RDBMS in every notebook (hsql, > > >mysql, postgresql or any $$ vendor base rdbms) an in a main site storing > > >the objects again in an opensource or $$vendor base dbms. > > > > > >Once the data collectors have a network connection available (either WAN > > >or LAN) we would like them to "replicate" their objects with the main site > > > >or with other partners. Scheduled or ad-hoc replication, it just doesn´t > > > >matter. OJB would do it no matter when or where. > > > > > >The apps have some business objects that will remain with little or no > > >changes through their life cycle (like the old master tables) ; some > > >others will face heavy updates (customers service requests). > > > > > >If any of you are familiar with it, Lotus Notes/Domino type of replication > > > >is the best model of the replication mechanism we would like to implement > > > >in this project (but remember, at an object or better business object > > >level replication, not record/document level replication). > > > > > >Let´s dream for a minute: OJB will let us replicate objects across > > >different dbms, without even having the same schema (due to the > > >repository.xml mapping magic!!!!) > > > > > >Among some other things, we will need to take care of things like unique > > >ids across db replicas ( sequencers ), differential replication, > > >replication conficts etc. > > > > > >Any frameworks or ideas out there? Any volunteers to start an "OJB > > >replicator" contribution to this great framework? > > > > > >Finally and again: Thanks Thomas and the whole OJB team!. > > > > > >Best regards, > > > > > >Gustavo Faerman > > >Buenos Aires, Argentina > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > - - > - Jason Pyeron http://www.pyerotechnics.com - > - Partner & Sr. Manager Pyerotechnics Development, Inc. - > - +1 (443) 451-2697 500 West University Parkway #1S - > - +1 (410) 808-6646 (c) Baltimore, Maryland 21210-3253 - > - - > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. If you > have received it in error, purge the message from your system and > notify the sender immediately. Any other use of the email by you > is prohibited. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
