cheers,
Mikko

The last_insert_id() example is basically the primary reason why I added possibility to use multiple queries the first place.

Having to modify program structure inside a transaction is actually a very common requirement for ErlyDB. Consider the following snippet:

<code>person:transaction(<br />
&nbsp;&nbsp;fun() -&amp;gt;<br />
&nbsp;&nbsp;&nbsp;&nbsp;P = person:new(&amp;quot;bob&amp;quot;),<br />
&nbsp;&nbsp;&nbsp;&nbsp;P1 = person:save(P), % executes INSERT followed by<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; % SELECT last_insert_id()<br />
&nbsp;&nbsp;&nbsp;&nbsp;people:add_person(P1)<br />
&nbsp;&nbsp;end).</code>

Without transparent handling of transactions by the MySQL driver, the auto-generated ErlyDB code would have to be much more complex in order to support this kind of usage.

In fact I think by doing this you are using SQL as kind of a variable alternative and that is not a good thing.

in fact I think it’s quite hard to find examples where you need to modify program structure inside SQL transaction.

I stil would not add new api functonality but instead would add a possibility to use lists or tuples inside lists to generate needed results (something I already do with my web framework),

something like

["begin transaction", 
 "insert...", 
 {"update X set Y=? where id=?", "select X,Y from Z"},
 "insert something new",
 "commit"

Just my 2 cents :-)
Mikko

This is essentially how I first solved the transaction issue. I added a list of statements to the transaction prior to sending them to the dispatcher, which then executed them one by one. The problem is that the results of the SELECT statement were unavailable to the statements that have followed it. This is the case also in your code if I understand it correctly.

Don’t worry about the double post — I’ll delete the redundant ones.

Thanks,
Yariv