Re: [SQLObject] The latest SVN checkout.

[Ian B. <ia...@co...>]

Peter Gebauer wrote:
> Hey there!
> 
> Just started working on my logging patch and when I was ready to try it out 
> I found out that there are differences from the latest SVN snapshot compared 
> to the 0.5.1 release, differences that break old code.
> 
> For instance, there is no SQLObject.new(). Any plans on updating the 
> examples and/or adding some documentation/comments to give a hint on how to 
> make new instances of SQLObjects?

The changes go with my general plans for 0.6.  I just committed them 
last night, so I haven't had a chance to update examples or docs, though 
tests are up to date.

Basically, the SQLObject package becomes sqlobject, and SQLObject.py 
becomes main.py.  .new() becomes __init__() (i.e., class instantiation 
creates a row), and you use .get() to retrieve an already-existant row.

> Also, I'd like to have some input on logging info. For the first try I just 
> replaced the printDebug() calls with debug messages, except the for the 
> unwarranted rollback which is a warning. (it raises an exception when 
> rollback or commit is executed outside transactions)
> 
> I might sum several queries, like automatic schema generation, to info 
> output and I will most likely add debug information for transactions too.
> Anything else I should think about?

That sounds good to me.  I don't know the overhead of sending a logging 
message when no one is paying attention, so I don't know if it's worth 
it to keep the connection debug attribute.  There's a good chance it 
doesn't matter.  The debug argument should stay, though, because that's 
an easy way to control output, and it could just configure the logger to 
print output to stdout.

I believe the logging package also introduces the concept of a hierarchy 
  of loggers.  So there could be, say, a general sqlobject logger, and 
per-connection loggers.  Or the connection logger could be a settable 
attribute.  Or there could be a general logger, and a SQL logger that 
logged all communication to the database.  I don't really have much 
experience to draw upon using that module.

I agree that schema generation, and perhaps some other stuff, can be at 
an INFO level, since it's definitely more interesting than other queries.

   Ian