[PEAK] Newbie Question

[Phillip J. Eby]

At 11:33 PM 12/6/03 +0000, William Trenker wrote:
>Do I need to explicitly "begin" a transaction?

Yes.  storage.beginTransaction(scopeObject), and 
storage.commitTransaction(scopeObject).

For simple applications, almost any scope object will suffice, because 
unless you explicitly declare otherwise, there's one transaction scope per 
root component.  So, if all the objects you're working with are part of the 
same tree, any one of them will suffice as a scope.

I've updated John's example on the Wiki to have the transaction.  I missed 
that issue when I reviewed it originally, because most of the time when I 
write DB code, the transaction has been created far outside the code that 
does the DB work.  And, that transaction is typically created by framework 
code, like ZPublisher.  So, I tend to forget that it's needed in short 
example code.


>   I thought that cursor.execute would wrap itself automatically in a 
> transaction.

What it does is to request that the connection *join* a transaction.  The 
DB connection looks up the transaction that it's in scope of, and asks to 
join it.  In your case, the problem is that the transaction isn't begun, so 
it can't join in, and an error is raised.

If you don't want the connection to join the transaction, you can pass 
'outsideTxn=True' along with the SQL, e.g.:

db("select foo from bar", outsideTxn=True)

This will tell the cursor to request that the connection *not* be in a 
transaction, and will give you an error if the connection has already 
joined a transaction.  This isn't something you'll likely use often, since 
it's mainly there to support databases (like Sybase) that have commands you 
can't use while a transaction is active.


>   But then maybe I'm thinking too much of the DB-API-2.0 spec.  Does 
> PEAK's cursor.execute require an explicit transaction?  How do I do that?

See above.


>For both of the above snippets I've set up an SQLite db called test.db and 
>created an aTable table with a single record.  It works fine with n2.

Yeah, n2 wraps everything up in a transaction.  Although really I'd like to 
have n2 be "transaction neutral", and do whatever you tell the DB to do, 
actually.  (Again, because of that whole Sybase thing.)  But that's a 
different discussion.  :)


>I should add that I don't mind tracing through the code trying to figure 
>out why tracebacks like the above are happening--I don't want to bother 
>you with trivial questions.  Could I ask what debugging tools you use to 
>work through tracebacks?  Do you just use pdb at the python command 
>prompt, or do you use one of the graphical debugging tools?  Any 
>recommendations?

I use pdb, when it's not obvious to me what the error is.  Usually it's 
obvious when I look at the code referenced by the traceback.  But that's 
talking about my errors *writing* PEAK, not using it.  :)