[elephant-devel] DB Transactions and UI

[Mariano Montone]

>
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20070628/c0839b51/attachment.html>