Re: [Modeling-users] Rollback?
Status: Abandoned
Brought to you by:
sbigaret
From:
<sbi...@us...> - 2006-09-12 10:14:10
|
Hi Wolgang & all, Wolfgang Keller wrote: > Hello, >=20 > just out of curiosity: >=20 > Is the possibility to rollback changes on the roadmap of Modeling? This= is=20 > for the case where several instances of an application using modeling r= un in=20 > parallel at different sites, and a transaction needs to be distributed = over=20 > more than one instance of the application... I'm not sure to understand what you mean by "a transaction needs to be di= stributed over more than one instance". If what follows doers not answer = your question, or if you need further explanations, please do not hesitat= e to ask. For the moment being, an EditingContext (EC) is the abstraction, at the o= bject level, of a transaction. One EC, one transaction, that can be commi= tted (hence, producing a transaction at the database level), or rolled ba= ck. You can also have sub-tranbsactions at the object level (see http://= modeling.sourceforge.net/UserGuide/nested-editing-context.html). Now as far as I understand it, your next question is about concurrent mod= ifications in different ECs. That can happen: in the same process, differ= ent threads, or in different processes --see below. > And, what would happen in Modeling if a different application, which do= es not=20 > pass through Modeling, but connects directly to the underlying database= ,=20 > modifies records in this database? Does Modeling go so far and notice w= hen a=20 > lock on a record is acquired by a different application, lock the=20 > corresponding object in memory, and then update the objects in memory w= ith=20 > the changes the other applications makes to the database? Or is such a=20 > function totally utopian? *duck* The features you ask for is partially addressed by a patch described here= : http://permalink.gmane.org/gmane.comp.python.modeling/374 although that they are addressed in a different but (imho) equivalent way= , as described below. With this patch: - an EditingContext saving changes broadcasts its changes to others, who = in turn merge the committed changes with their own, uncommitted, changes. (for now, this only works within the same process, with e.g. ECs dispatch= ed in different threads, but NOT for ECs that are created in different pr= ocesses) - if, as you described, an external application changes some database val= ues, any EC saving its changes will receive an OptimisticLockingFailure e= xception when trying to save changes on some of the externally modified d= atas. In this case: external application=3D=3Dan other process; it can be anyth= ing modifying the db, and particularly: an other application using the mo= deling framework. This is obviously the first step, in further development the externally m= odified objects would be sent back to the EC so that you can choose to re= fresh the values, examine the differences and accept or discard the chang= es. Explicit database-locking would be called Pessimlistic Locking, where mod= ifying an object implies acquiring a lock on the corresponding database c= olumn(s) until changes are saved (or discarded). This feature is on the = TODO list, but development has not started yet. -- S=E9bastien. Wolfgang Keller wrote: > Hello, >=20 > just out of curiosity: >=20 > Is the possibility to rollback changes on the roadmap of Modeling? This= is=20 > for the case where several instances of an application using modeling r= un in=20 > parallel at different sites, and a transaction needs to be distributed = over=20 > more than one instance of the application... >=20 > And, what would happen in Modeling if a different application, which do= es not=20 > pass through Modeling, but connects directly to the underlying database= ,=20 > modifies records in this database? Does Modeling go so far and notice w= hen a=20 > lock on a record is acquired by a different application, lock the=20 > corresponding object in memory, and then update the objects in memory w= ith=20 > the changes the other applications makes to the database? Or is such a=20 > function totally utopian? *duck* >=20 > TIA, >=20 > Sincerely, >=20 > Wolfgang Keller >=20 |