Re: [Patch] Update view-database only if the transaction succeeded

>  Please take a
> look at the git-am manual page for more info about on formatting of
> your submission, especially about how the body of the message becomes
> the commit message (see below).

Will do. Thanks for the pointer.

> To preserve backward compatibility with applications that expect the
> database slot to be immediately updated after a store, as well as be
> more consistent with the semantics of a SQL transaction, I think the
> right thing to do is to fill the database slot of objects immediately
> after a store. However, if a transaction ends before it is committed,
> then at that time the database slot of the modified objects should be
> returned to their initial states.

Yup. I think that's a better idea. Until and unless the transaction is
rolled back (or aborted) the current DB connection is going to "see"
the objects in the DB. So what you've suggested is the right thing to
do.

> This variable declaration should be at the top of the
> transactions.lisp file as it has nothing to do with what's in the
> database.lisp file. Note in clsql.asd that the functional module is
> loaded before the object module.

> Remove the empty comment line ";;;" as it provides no value.

Heh. Just my cruft to make code more readable. Coloured markers in
Emacs for free!

> However, please add a documentation string to
> the defvar form.

Would've done that. The only problem being that doing so forces me to
bind the symbol name to something. I've explained why I want
*transaction-insert-list* to be unbound below.

> This variable should hold a stack of lists to properly handle nested transactions.

My solution is based on the assumption that most use-cases for
transactions will use the with-transaction macro. My solution works
optimally only in such a scenario because I'm binding the
*transaction-insert-list* variables in the let form in the macro. By
doing so I get the Lisp magic of dynamic scoping. With dynamic scoping
*transaction-insert-list* will always be bound correctly in a
multi-threaded environment or in nested transactions or whatever.

On second thoughts I can probably bind *transaction-insert-list* to
nil and give that doc-string and depend on something else to determine
whether *transaction-insert-list* was bound in a dynamic context or
not.

Hope you understand what I'm trying to say. Explaining these abstracts
concepts is hard on email :-)

Saurabh.
-- 
http://nandz.blogspot.com
http://foodieforlife.blogspot.com