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
|
