public inbox for [email protected]
help / color / mirror / Atom feedRe: Detecting test failures reported as warnings
4+ messages / 2 participants
[nested] [flat]
* Re: Detecting test failures reported as warnings
@ 2020-06-17 19:31 Chapman Flack <[email protected]>
2020-06-17 19:42 ` Re: Detecting test failures reported as warnings Kartik Ohri <[email protected]>
2020-07-08 21:37 ` Re: Detecting test failures reported as warnings Chapman Flack <[email protected]>
0 siblings, 2 replies; 4+ messages in thread
From: Chapman Flack @ 2020-06-17 19:31 UTC (permalink / raw)
To: Kartik Ohri <[email protected]>; +Cc: [email protected]
On 06/17/20 13:15, Kartik Ohri wrote:
> Out of the box, Powershell only supports MySQL server. ODBC drivers will be
> required to be built from source for use with Powershell which I think will
> not be worth the complexity.
Agreed.
> JDBC driver for Java or using python may be a
> viable option. I haven't had much success with the python version though.
I was looking at the various Python driver choices myself the other night
and it wasn't as promising as I thought. pg8000 was the pure-Python one
that I remembered, but can't access warnings (as far as I can tell).
py-postgresql looks quite promising and has message hooks, but even it
has native components, as do several others. I stopped before completing
an exhaustive survey.
There's a lot to like about a Java and JDBC approach. It shouldn't be hard
to get off the ground, JDBC has a nice standard API for finding out about
warnings (and reading through the pgJDBC code, I believe it is implemented,
though I haven't done a test yet).
Later on, as the prerequisites for migrating to TAP get accomplished,
that code could just be evolved to match.
> In any case, a very simple query suppressed INFO outputs SET
> client_min_messages TO WARNING. What should be the behaviour if warnings
> are found ? Should be marked as failed or passing.
My convention in the existing tests has been to use INFO to report
success, and WARNING to report failure. The idea would be to let the
test progress as far as it can, even complete if possible, but give an
overall not-passing result if there were warnings.
Regards,
-Chap
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Detecting test failures reported as warnings
2020-06-17 19:31 Re: Detecting test failures reported as warnings Chapman Flack <[email protected]>
@ 2020-06-17 19:42 ` Kartik Ohri <[email protected]>
2020-06-17 19:53 ` Re: Detecting test failures reported as warnings Chapman Flack <[email protected]>
1 sibling, 1 reply; 4+ messages in thread
From: Kartik Ohri @ 2020-06-17 19:42 UTC (permalink / raw)
To: Chapman Flack <[email protected]>; +Cc: [email protected]
>
> There's a lot to like about a Java and JDBC approach. It shouldn't be hard
> to get off the ground, JDBC has a nice standard API for finding out about
> warnings (and reading through the pgJDBC code, I believe it is implemented,
> though I haven't done a test yet).
>
> Later on, as the prerequisites for migrating to TAP get accomplished,
> that code could just be evolved to match.
>
As of now, setting client log level seems to work very well. Should I try
to work out this approach or go ahead?
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Detecting test failures reported as warnings
2020-06-17 19:31 Re: Detecting test failures reported as warnings Chapman Flack <[email protected]>
2020-06-17 19:42 ` Re: Detecting test failures reported as warnings Kartik Ohri <[email protected]>
@ 2020-06-17 19:53 ` Chapman Flack <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Chapman Flack @ 2020-06-17 19:53 UTC (permalink / raw)
To: Kartik Ohri <[email protected]>; +Cc: [email protected]
On 06/17/20 15:42, Kartik Ohri wrote:
>> There's a lot to like about a Java and JDBC approach. It shouldn't be hard
>> to get off the ground, JDBC has a nice standard API for finding out about
>> warnings (and reading through the pgJDBC code, I believe it is implemented,
>> though I haven't done a test yet).
>>
>> Later on, as the prerequisites for migrating to TAP get accomplished,
>> that code could just be evolved to match.
>>
> As of now, setting client log level seems to work very well. Should I try
> to work out this approach or go ahead?
That sounds adequate for now. Especially if log_min_messages is still
at INFO (or could even go finer than that), and you can limit just the
client messages to warning, use that to detect success/failure, but put
the backend log into the build log.
Regards,
-Chap
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Detecting test failures reported as warnings
2020-06-17 19:31 Re: Detecting test failures reported as warnings Chapman Flack <[email protected]>
@ 2020-07-08 21:37 ` Chapman Flack <[email protected]>
1 sibling, 0 replies; 4+ messages in thread
From: Chapman Flack @ 2020-07-08 21:37 UTC (permalink / raw)
To: [email protected]
On 06/17/20 15:31, Chapman Flack wrote:
> I was looking at the various Python driver choices myself the other night
> and it wasn't as promising as I thought. pg8000 was the pure-Python one
> that I remembered, but can't access warnings (as far as I can tell).
For the record, so no future reader of this thread is misinformed, I was
wrong about that. pg8000 does make notices/warnings available, using the
'notices' property of a pg8000 Connection. It is a deque that will hold
the most recent not-more-than-100 that were received. popleft() will
retrieve them in arrival order.
Each item is a dict that presents all of the fields of the PostgreSQL
notice, keyed by their single-character codes:
https://www.postgresql.org/docs/9.6/protocol-error-fields.html
So, not only was I mistaken to say "can't access", it in fact provides
better access than many other PG drivers.
Errors are a bit botched: those raise exceptions of course, and the
exception will have a tuple of values. Those are the values of all
the fields received from PostgreSQL, just as in the warning case, but
with all the keys thrown away, leaving you to guess which field is which.
-Chap
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2020-07-08 21:37 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-06-17 19:31 Re: Detecting test failures reported as warnings Chapman Flack <[email protected]>
2020-06-17 19:42 ` Kartik Ohri <[email protected]>
2020-06-17 19:53 ` Chapman Flack <[email protected]>
2020-07-08 21:37 ` Chapman Flack <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox