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
|