[elephant-devel] DB Transactions and UI

[Ian Eslick]

Perhaps a combination of variable isolation types and nested  
transactions would solve your problem.

http://www.oracle.com/technology/documentation/berkeley-db/db/ref/ 
transapp/read.html
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/ 
transapp/nested.html

Elephant supports all these modes on the BDB data store only.  SQL  
provides no nesting and I don't believe it supports relaxed  
transaction isolation modes.

Ian


On Jun 28, 2007, at 1:29 PM, Mariano Montone wrote:

> > There are cases in which a user wants to perform several  
> operations in
> > a transactional way.
>
> Do you have examples? The only cases where my own apps needed several
> pages for an operation were creation operation, IIRC. On the other  
> hand,
> there is at least one famous example, namely most online shops  
> checkout
> operation. On Amazon, ISTR you go through 3 or 4 pages to checkout. I
> never tried to update my cart while doing that. I wonder how it  
> behaves.
>
> There's a very simple one which appears almost everywhere in our  
> framework and is currently unsolved.
>
> Suppose you have an object which has a collection of some other  
> objects. You want to generate automatically a creator component for  
> it. We wish we could add and remove items to and from the object at  
> the creation moment (suppose there's a UI design reason for doing  
> that). Now, let's complicate things a bit further just to make the  
> example clearer. Suppose the collection has a domain of possible  
> objects, for example, represented by the following OQL (Object  
> Query Language) expression:
> select item:CollectionItem from object: EditedObject where not  
> exists (object.collection as collectionItem where collectionItem is  
> item). That is to say, the user can choose from a list of items  
> that makes sense adding to the object's collection (those items  
> that do not already are in the object's collection). The problems  
> for doing this are:
> 1) In a RDBM (MySQL in particular) we cannot reason about a non  
> existent object (in this case object:EditedObject) if it is not  
> already inserted in the DB, unless we are in a transaction. We  
> could do that if we had long transactions and could create the  
> object in it and then display the creator component.
> 2) Each addition and removal triggers a request and if we want to  
> be able use that OQL expression for the UI, then we cannot simply  
> put things in memory. We would have to implement in-memory querys,  
> but it is not clear to me how to do it, or if it makes sense. So we  
> have to add and remove items to the db, each in a short  
> transaction. Note that the UI depends on putting things on the DB  
> in order to give feedback to the user because of the way he gets  
> objects it want's to display (through that query expression).
>
> Although you may think this is a little overcomplicated, this kind  
> of UI arises in lots of places in my applications and the solution  
> is to sacrifice that UI design and force the user to create the  
> object in two stages. First, he creates the object with out  
> modifying the collection. In the following stage, he is allowed to  
> modify the collection in a separate screen (after the object has  
> been created in the db and I can reason about it with that kind of  
> OQL expressions in the DB).
>
> Mariano
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel