Chris Clark wrote:
> My 2 cents. I agree that logging isn't something that _must_ be part of
> a driver but logging is extremely useful. I think we are looking at
> another case where we need a higher level manager (along the lines of
> the wrapper example) something akin to the ODBC driver mana
On 2006-1123 20:05:55, Dieter Maurer wrote:
> You have not read carefully enough:
>
> The logger used (while not the Python logger) has had the same
> behaviour -- it discarded messages based on the log level.
> *BUT* the quadadric runtime went into determining the
> parameters for the log
Mario Frasca wrote at 2006-11-22 22:26 +0100:
>
>> I have seen discarded logging generate a quadratic runtime behavior:
>>
>> This occured as follows: [...]
>
>funny. but this is not a problem here, since discarding a logging call
>is done just based on the 'level' of the logger and the 'l
On 2006-1122 19:57:07, Dieter Maurer wrote:
> Usually, I do not want to see logs of database operations
> (as they may contain sensible information) *BUT* if I am
> analysing problems with database interaction, I want such
> operations logged.
the standard logging module solves this quite nicely.
Mario Frasca wrote at 2006-11-21 16:46 +0100:
> ...
>as I see it, logging has to do with every module, so since there is a
>standard logging module, my feeling is that there could be also a
>standard logging policy...
I do not think so...
Usually, I do not want to see logs of database operations
M.-A. Lemburg wrote:
>Mario Frasca wrote:
>
>
>>On 2006-1121 16:23:26, M.-A. Lemburg wrote:
>>
>>
>>>Mario Frasca wrote:
>>>
>>>
[...] it would be nice (I mean, I think it would)
if also the logging policy would be stated in the db-api2++
>>>I'm not really su
M.-A. Lemburg wrote:
>> The major things I think we can standardize:
>>
>> * There's no common way to configure databases. I'd like to see a
>> single URI syntax that everyone can use. This should be modestly
>> extensible via query string parameters.
>
> There has been some discussion about t
Ian Bicking wrote:
> I probably won't have the time to really follow this through, but since
> there has been a little discussion of this stuff lately I'd like to
> throw out an idea for where I think Python database standards should go.
> This mostly builds on the dbapi rather than extending
I probably won't have the time to really follow this through, but since
there has been a little discussion of this stuff lately I'd like to
throw out an idea for where I think Python database standards should go.
This mostly builds on the dbapi rather than extending it directly (I
think).
Th
