Hi,
I've make a patch which insert notices concepts to PDO. It create:
- PDO::noticeInfo() - to be like errorInfo
- PDO::ATTR_LOG_NOTICES, the name of the PDO parameter
- PDO::NOTICES_FETCH - fetch notices
- PDO::NOTICES_NONE - don't fetch notices
The notices HashTable is emptied at each queries.
There is a patch to implements this function into PDO:
http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-notices-managment.patch
And one other to implements notices recuperation for PostgreSQL:
http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-pgsql-notices-managment.patch
It can be done for Oracle, i'm sure.
Thanks for feedbacks.
Samuel.
There's an example, using PostgreSQL driver:
<?php
$sql = new PDO('pgsql:host=localhost;dbname=postgres', 'postgres', '',
array(
PDO::ATTR_LOG_NOTICES => PDO::NOTICES_FETCH
));
var_dump($sql);
echo "getAttribute: ";
var_dump($sql->getAttribute(PDO::ATTR_LOG_NOTICES));
echo 'Notices: '; var_dump($sql->noticeInfo());
$q1 = $sql->query('CREATE OR REPLACE FUNCTION test_notice (v_int
integer) RETURNS integer AS $$
BEGIN
RAISE NOTICE 'Sympatique % !', v_int;
RAISE NOTICE 'Sympatique un nouvelle fois % !', v_int;
RAISE NOTICE 'Génial maintenant... % ', v_int;
RETURN 12;
END;
$$ LANGUAGE plpgsql;');
$q2 = $sql->query('SELECT * FROM test_notice(1)');
echo 'Query: '; var_dump($q2);
echo 'Notices: '; var_dump($sql->noticeInfo());
?>
That will return:
object(PDO)#1 (0) {
}
getAttribute: bool(true)
Notices: bool(false)
Query: object(PDOStatement)#3 (1) {
["queryString"]=>
string(28) "SELECT * FROM test_notice(1)"
}
Notices: array(3) {
[0]=>
string(23) "NOTICE: Sympatique 1 !"
[1]=>
string(40) "NOTICE: Sympatique un nouvelle fois 1 !"
[2]=>
string(33) "NOTICE: Génial maintenant... 1 "
}
Query: object(PDOStatement)#4 (1) {
["queryString"]=>
string(10) "SELECT 1,2"
}
Notices: bool(false)
Samuel.
Le jeudi 08 octobre 2009 à 23:51 +0200, Samuel ROZE a écrit :
Hi,
I've make a patch which insert notices concepts to PDO. It create:
- PDO::noticeInfo() - to be like errorInfo
- PDO::ATTR_LOG_NOTICES, the name of the PDO parameter
- PDO::NOTICES_FETCH - fetch notices
- PDO::NOTICES_NONE - don't fetch notices
The notices HashTable is emptied at each queries.
There is a patch to implements this function into PDO:
http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-notices-managment.patchAnd one other to implements notices recuperation for PostgreSQL:
http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-pgsql-notices-managment.patchIt can be done for Oracle, i'm sure.
Thanks for feedbacks.
Samuel.
Samuel ROZE wrote:
Hi,
I've make a patch which insert notices concepts to PDO. It create:
- PDO::noticeInfo() - to be like errorInfo
- PDO::ATTR_LOG_NOTICES, the name of the PDO parameter
- PDO::NOTICES_FETCH - fetch notices
I initially took "FETCH" to mean it was related to a query; this
wouldn't always be the case. What about calling it NOTICES_ENABLE?
Chris
--
Blog: http://blogs.oracle.com/opal
Twitter: http://twitter.com/ghrd
It's a good idea.
- PDO::NOTICES_FETCH -> PDO::NOTICES_ENABLED
- PDO::NOTICES_NONE -> PDO::NOTICES_DISABLED
That's better ?
I see that you are from the Oracle team. Can you explain me how oracle
works to raise notices like PostgreSQL ? Or can you build a proof of
concept to get notices from Oracle ?
Thanks.
Samuel.
Le jeudi 08 octobre 2009 à 15:22 -0700, Christopher Jones a écrit :
Samuel ROZE wrote:
Hi,
I've make a patch which insert notices concepts to PDO. It create:
- PDO::noticeInfo() - to be like errorInfo
- PDO::ATTR_LOG_NOTICES, the name of the PDO parameter
- PDO::NOTICES_FETCH - fetch noticesI initially took "FETCH" to mean it was related to a query; this
wouldn't always be the case. What about calling it NOTICES_ENABLE?Chris
Samuel ROZE wrote:
It's a good idea.
- PDO::NOTICES_FETCH -> PDO::NOTICES_ENABLED
- PDO::NOTICES_NONE -> PDO::NOTICES_DISABLED
That's better ?
That works.
I see that you are from the Oracle team. Can you explain me how oracle
works to raise notices like PostgreSQL ? Or can you build a proof of
concept to get notices from Oracle ?
I'm equating your NOTICES to Oracle's DBMS_OUTPUT. See "Getting
Output with DBMS_OUTPUT" on p 181 of:
http://www.oracle.com/technology/tech/php/underground-php-oracle-manual.html
Something similar could be coded in the PDO driver.
The amount of text output could be quite large, depending on the
user's coding style. Is your design extensible enough to allow for
streaming/chunking if the interface needs to be enhanced?
PL/SQL also has compile time warnings and errors that are handled
differently, see "PL/SQL Success With Information Warnings" on p167.
Chris
Thanks.
Samuel.Le jeudi 08 octobre 2009 à 15:22 -0700, Christopher Jones a écrit :
Samuel ROZE wrote:
Hi,
I've make a patch which insert notices concepts to PDO. It create:
- PDO::noticeInfo() - to be like errorInfo
- PDO::ATTR_LOG_NOTICES, the name of the PDO parameter
- PDO::NOTICES_FETCH - fetch notices
I initially took "FETCH" to mean it was related to a query; this
wouldn't always be the case. What about calling it NOTICES_ENABLE?Chris
--
Blog: http://blogs.oracle.com/opal
Twitter: http://twitter.com/ghrd
Christopher Jones ha scritto:
Samuel ROZE wrote:
It's a good idea.
- PDO::NOTICES_FETCH -> PDO::NOTICES_ENABLED
- PDO::NOTICES_NONE -> PDO::NOTICES_DISABLED
That's better ?
That works.
I see that you are from the Oracle team. Can you explain me how oracle
works to raise notices like PostgreSQL ? Or can you build a proof of
concept to get notices from Oracle ?I'm equating your NOTICES to Oracle's DBMS_OUTPUT. See "Getting
Output with DBMS_OUTPUT" on p 181 of:http://www.oracle.com/technology/tech/php/underground-php-oracle-manual.html
Something similar could be coded in the PDO driver.
The amount of text output could be quite large, depending on the
user's coding style. Is your design extensible enough to allow for
streaming/chunking if the interface needs to be enhanced?
How about:
PDO::NOTICES_DISABLED
PDO::NOTICES_ARRAY
to allow space for different formats (e.g. PDO::NOTICES_RESULTSET)?
PL/SQL also has compile time warnings and errors that are handled
differently, see "PL/SQL Success With Information Warnings" on p167.
However, having read the above chapter, it seems to me that error code
24344 with its warnings is more similar to MySQL warnings and PgSQL
notices. Which one should be automatically handled by PDO? I'd vote for
this one, leaving DBMS_OUTPUT still available by manually sending the
queries highligthed in your book.
Cheers
Matteo Beccati
PDO::NOTICES_DISABLED
PDO::NOTICES_ARRAYto allow space for different formats (e.g. PDO::NOTICES_RESULTSET)?
I not but what is the real interest of returning another type of data.
And, what can be the other type ? It can have one notice as having
many.
PL/SQL also has compile time warnings and errors that are handled
differently, see "PL/SQL Success With Information Warnings" on p167.However, having read the above chapter, it seems to me that error code
24344 with its warnings is more similar to MySQL warnings and PgSQL
notices. Which one should be automatically handled by PDO? I'd vote for
this one, leaving DBMS_OUTPUT still available by manually sending the
queries highligthed in your book.
For your mind, PDO's Oracle driver have to catch the error #24344 to
put it into notices and leave the user request Oracle database to have
DBMS_OUTPUT's notices ? I disagree because DBMS_OUTPUT must be used in
Pl/SQL functions, which must raise notices which are needed by the
user...
Cheers
Matteo Beccati
Well, if I understood, DBMS_OUTPUT returns user's notices or warning,
but no errors ?
In the standart way, in console, how the notices are printed ?
Is DBMS_OUTPUT used both by Pl/SQL function and Oracle functions?
Thanks.
Samuel.
2009/10/9 Christopher Jones christopher.jones@oracle.com:
Samuel ROZE wrote:
It's a good idea.
- PDO::NOTICES_FETCH -> PDO::NOTICES_ENABLED
- PDO::NOTICES_NONE -> PDO::NOTICES_DISABLED
That's better ?
That works.
I see that you are from the Oracle team. Can you explain me how oracle
works to raise notices like PostgreSQL ? Or can you build a proof of
concept to get notices from Oracle ?I'm equating your NOTICES to Oracle's DBMS_OUTPUT. See "Getting
Output with DBMS_OUTPUT" on p 181 of:http://www.oracle.com/technology/tech/php/underground-php-oracle-manual.html
Something similar could be coded in the PDO driver.
The amount of text output could be quite large, depending on the
user's coding style. Is your design extensible enough to allow for
streaming/chunking if the interface needs to be enhanced?PL/SQL also has compile time warnings and errors that are handled
differently, see "PL/SQL Success With Information Warnings" on p167.Chris
Thanks.
Samuel.Le jeudi 08 octobre 2009 à 15:22 -0700, Christopher Jones a écrit :
Samuel ROZE wrote:
Hi,
I've make a patch which insert notices concepts to PDO. It create:
- PDO::noticeInfo() - to be like errorInfo
- PDO::ATTR_LOG_NOTICES, the name of the PDO parameter
- PDO::NOTICES_FETCH - fetch notices
I initially took "FETCH" to mean it was related to a query; this
wouldn't always be the case. What about calling it NOTICES_ENABLE?Chris
--
Blog: http://blogs.oracle.com/opal
Twitter: http://twitter.com/ghrd
Just a little question:
- How I can propose my patch to be merged to PHP ?
Rather suggest.. :-)
Le jeudi 08 octobre 2009 à 23:51 +0200, Samuel ROZE a écrit :
Hi,
I've make a patch which insert notices concepts to PDO. It create:
- PDO::noticeInfo() - to be like errorInfo
- PDO::ATTR_LOG_NOTICES, the name of the PDO parameter
- PDO::NOTICES_FETCH - fetch notices
- PDO::NOTICES_NONE - don't fetch notices
The notices HashTable is emptied at each queries.
There is a patch to implements this function into PDO:
http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-notices-managment.patchAnd one other to implements notices recuperation for PostgreSQL:
http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-pgsql-notices-managment.patchIt can be done for Oracle, i'm sure.
Thanks for feedbacks.
Samuel.
Hi,
First thanks to have updated the patch according to our last feedback :)
About applying it, we should wait a bit more until we get more
feedbacks (say until the middle of next week). Then see how we can do
it for the other drivers at the same time.
Cheers,
Pierre
Just a little question:
- How I can propose my patch to be merged to PHP ?
Rather suggest.. :-)
Le jeudi 08 octobre 2009 à 23:51 +0200, Samuel ROZE a écrit :
Hi,
I've make a patch which insert notices concepts to PDO. It create:
- PDO::noticeInfo() - to be like errorInfo
- PDO::ATTR_LOG_NOTICES, the name of the PDO parameter
- PDO::NOTICES_FETCH - fetch notices
- PDO::NOTICES_NONE - don't fetch noticesThe notices HashTable is emptied at each queries.
There is a patch to implements this function into PDO:
http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-notices-managment.patchAnd one other to implements notices recuperation for PostgreSQL:
http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-pgsql-notices-managment.patchIt can be done for Oracle, i'm sure.
Thanks for feedbacks.
Samuel.--
--
Pierre
Le vendredi 09 octobre 2009 à 23:05 +0200, Pierre Joye a écrit :
About applying it, we should wait a bit more until we get more
feedbacks (say until the middle of next week).
Oh yeah of course ! It was just a question to know how it happened. ;-)
Then see how we can do it for the other drivers at the same time.
I'm looking for Oracle.
Is somebody know how we can do for MySQL (and how raise notices with
it) ?
Cheers,
Pierre
Just a little question:
- How I can propose my patch to be merged to PHP ?
Rather suggest.. :-)
Le jeudi 08 octobre 2009 à 23:51 +0200, Samuel ROZE a écrit :
Hi,
I've make a patch which insert notices concepts to PDO. It create:
- PDO::noticeInfo() - to be like errorInfo
- PDO::ATTR_LOG_NOTICES, the name of the PDO parameter
- PDO::NOTICES_FETCH - fetch notices
- PDO::NOTICES_NONE - don't fetch noticesThe notices HashTable is emptied at each queries.
There is a patch to implements this function into PDO:
http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-notices-managment.patchAnd one other to implements notices recuperation for PostgreSQL:
http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-pgsql-notices-managment.patchIt can be done for Oracle, i'm sure.
Thanks for feedbacks.
Samuel.
Le vendredi 09 octobre 2009 à 23:05 +0200, Pierre Joye a écrit :
About applying it, we should wait a bit more until we get more
feedbacks (say until the middle of next week).Oh yeah of course ! It was just a question to know how it happened. ;-)
Then see how we can do it for the other drivers at the same time.
I'm looking for Oracle.
Is somebody know how we can do for MySQL (and how raise notices with
it) ?
http://dev.mysql.com/doc/refman/5.1/en/show-warnings.html
Cheers,
Pierre
Just a little question:
- How I can propose my patch to be merged to PHP ?
Rather suggest.. :-)
Le jeudi 08 octobre 2009 à 23:51 +0200, Samuel ROZE a écrit :
Hi,
I've make a patch which insert notices concepts to PDO. It create:
- PDO::noticeInfo() - to be like errorInfo
- PDO::ATTR_LOG_NOTICES, the name of the PDO parameter
- PDO::NOTICES_FETCH - fetch notices
- PDO::NOTICES_NONE - don't fetch noticesThe notices HashTable is emptied at each queries.
There is a patch to implements this function into PDO:
http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-notices-managment.patchAnd one other to implements notices recuperation for PostgreSQL:
http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-pgsql-notices-managment.patchIt can be done for Oracle, i'm sure.
Thanks for feedbacks.
Samuel.
Ferenc Kovacs wrote:
Then see how we can do it for the other drivers at the same time.
I'm looking for Oracle.
Is somebody know how we can do for MySQL (and how raise notices with
it) ?
Something to consider here is that, like MySQL in this case, many of
these types of activity ARE now available as SQL queries and so do not
have to be handled specially by the driver. It is only those areas where
the results are only available by non-SQL calls that should be added as
special cases. PDO has no interest in mapping SQL between different
engines! Carrying out additional SQL calls in the background to emulate
functions required by other drivers just seems wrong? The Firebird
engine has been working to move all of the 'service' facilities which
would normally be handled directly by the driver into simple SQL queries
to get around this problem from the other end.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Le samedi 10 octobre 2009 à 15:51 +0100, Lester Caine a écrit :
Ferenc Kovacs wrote:
Then see how we can do it for the other drivers at the same time.
I'm looking for Oracle.
Is somebody know how we can do for MySQL (and how raise notices with
it) ?Something to consider here is that, like MySQL in this case, many of
these types of activity ARE now available as SQL queries and so do not
have to be handled specially by the driver. It is only those areas where
the results are only available by non-SQL calls that should be added as
special cases. PDO has no interest in mapping SQL between different
engines! Carrying out additional SQL calls in the background to emulate
functions required by other drivers just seems wrong? The Firebird
engine has been working to move all of the 'service' facilities which
would normally be handled directly by the driver into simple SQL queries
to get around this problem from the other end.
It is the case for MySQL and Oracle...so for your mind, we don't have to
make this option available ? I disagree because PDO want make that PHP
codes support many Databases and if I want to get this notices on MySQL,
I can use "SHOW WARNING" but, if my apps is used on PostgreSQL, my query
will fail ! If I can use PDO::noticeInfo in MySQL and in PostgreSQL, it
will be great. :-)
And we have to know that these additional requests will be executed only
if PDO::ATTR_LOG_NOTICES is turned to 1 ! So user want them... ;-)
--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Le samedi 10 octobre 2009 à 15:51 +0100, Lester Caine a écrit :
Ferenc Kovacs wrote:
Then see how we can do it for the other drivers at the same time.
I'm looking for Oracle.
Is somebody know how we can do for MySQL (and how raise notices
with
it) ?Something to consider here is that, like MySQL in this case, many of
these types of activity ARE now available as SQL queries and so do
not
have to be handled specially by the driver. It is only those areas
where
the results are only available by non-SQL calls that should be
added as
special cases. PDO has no interest in mapping SQL between different
engines! Carrying out additional SQL calls in the background to
emulate
functions required by other drivers just seems wrong? The Firebird
engine has been working to move all of the 'service' facilities which
would normally be handled directly by the driver into simple SQL
queries
to get around this problem from the other end.It is the case for MySQL and Oracle...so for your mind, we don't
have to
make this option available ? I disagree because PDO want make that PHP
codes support many Databases and if I want to get this notices on
MySQL,
I can use "SHOW WARNING" but, if my apps is used on PostgreSQL, my
query
will fail ! If I can use PDO::noticeInfo in MySQL and in PostgreSQL,
it
will be great. :-)And we have to know that these additional requests will be executed
only
if PDO::ATTR_LOG_NOTICES is turned to 1 ! So user want them... ;-)
i do agree that we need to choose wisely, where we abstract.
furthermore PDO at least currently doesnt really aim to offer a
complete solution for portability in the sense that it leaves out a
lot of features that would be required to make apps portable on the
SQL level. however i personally think this case seems legit enough to
get handled. more importantly we have someone working out the
necessary code and there is little chance if it having adverse effects
on any existing stuff ..
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Samuel ROZE wrote:
Le samedi 10 octobre 2009 à 15:51 +0100, Lester Caine a écrit :
Ferenc Kovacs wrote:
Then see how we can do it for the other drivers at the same time.
I'm looking for Oracle.
Is somebody know how we can do for MySQL (and how raise notices with
it) ?http://dev.mysql.com/doc/refman/5.1/en/show-warnings.html
Something to consider here is that, like MySQL in this case, many of
these types of activity ARE now available as SQL queries and so do not
have to be handled specially by the driver. It is only those areas where
the results are only available by non-SQL calls that should be added as
special cases. PDO has no interest in mapping SQL between different
engines! Carrying out additional SQL calls in the background to emulate
functions required by other drivers just seems wrong? The Firebird
engine has been working to move all of the 'service' facilities which
would normally be handled directly by the driver into simple SQL queries
to get around this problem from the other end.It is the case for MySQL and Oracle...so for your mind, we don't have to
make this option available ? I disagree because PDO want make that PHP
codes support many Databases and if I want to get this notices on MySQL,
I can use "SHOW WARNING" but, if my apps is used on PostgreSQL, my query
will fail ! If I can use PDO::noticeInfo in MySQL and in PostgreSQL, it
will be great. :-)
Samuel - the most important thing to note here is that MOST additional
MySQL SQL will fail on Postgres and many other database. PDO does
nothing about the SQL and so while a LOT of projects have switched TO
PDO, the result is LESS compatibility at the SQL level. Two of the
projects I work with have made a switch that now makes them unusable
with Firebird and I've had to switch my own builds BACK to ADOdb simply
to restore the SQL compatibility. People are using PDO, but only with a
single database! There is no consensus yet on making the SQL transparent
to each driver.
And we have to know that these additional requests will be executed only
if PDO::ATTR_LOG_NOTICES is turned to 1 ! So user want them... ;-)
But the actual notices returned WILL be different for each database and
have to be handled separately in each case anyway?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Le samedi 10 octobre 2009 à 19:43 +0100, Lester Caine a écrit :
[...]
It is the case for MySQL and Oracle...so for your mind, we don't have to
make this option available ? I disagree because PDO want make that PHP
codes support many Databases and if I want to get this notices on MySQL,
I can use "SHOW WARNING" but, if my apps is used on PostgreSQL, my query
will fail ! If I can use PDO::noticeInfo in MySQL and in PostgreSQL, it
will be great. :-)Samuel - the most important thing to note here is that MOST additional
MySQL SQL will fail on Postgres and many other database. PDO does
nothing about the SQL and so while a LOT of projects have switched TO
PDO, the result is LESS compatibility at the SQL level. Two of the
projects I work with have made a switch that now makes them unusable
with Firebird and I've had to switch my own builds BACK to ADOdb simply
to restore the SQL compatibility. People are using PDO, but only with a
single database! There is no consensus yet on making the SQL transparent
to each driver.
I agree that for high SQL level, using a simple connexion abstraction
isn't sufficient. But PDO is in many cases like a Database abstraction
because each Databases supports minimal SQL syntax.
For notices, it IS different because they can be wanted by anybody whose
codes use PDO... From the novice to the high SQL experience using PDO
instead of PHP basic drivers.
And we have to know that these additional requests will be executed only
if PDO::ATTR_LOG_NOTICES is turned to 1 ! So user want them... ;-)But the actual notices returned WILL be different for each database and
have to be handled separately in each case anyway?
Get notices is different on each Database, yeah. That's why we have to
develop a basic function which returns notices raised by the Database
PDO's driver. ;-)
Hi:
If the notice/warning gathering abstraction is going to be sending
queries to the DBMS in the background, one needs to be careful about
maintaining both the results and metadata from the original query that
caused the warnings.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Hi,
Le dimanche 11 octobre 2009 à 11:55 -0400, Daniel Convissor a écrit :
Hi:
If the notice/warning gathering abstraction is going to be sending
queries to the DBMS in the background, one needs to be careful about
maintaining both the results and metadata from the original query that
caused the warnings.
For PostgreSQL, we don't need. For MySQL and Oracle, we need but this
will be in an other function builds for. (so it will do NOT change the
original query's data).
Samuel.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
If the notice/warning gathering abstraction is going to be sending
queries to the DBMS in the background, one needs to be careful about
maintaining both the results and metadata from the original query that
caused the warnings.
hmm why do you think that PDO would need to take special care about
this? seems like this is the job of the PDO using code ..
but it does raise one concern that i did not think about before: one
potential issue is that with unbuffered queries (which are on by
default) in MySQL you can only have one open result set at a time, so
you cant check the notices until you have fetched the result set ..
then again notices are usually only for insert/delete/update ..
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith wrote:
If the notice/warning gathering abstraction is going to be sending
queries to the DBMS in the background, one needs to be careful about
maintaining both the results and metadata from the original query that
caused the warnings.hmm why do you think that PDO would need to take special care about
this? seems like this is the job of the PDO using code ..but it does raise one concern that i did not think about before: one
potential issue is that with unbuffered queries (which are on by
default) in MySQL you can only have one open result set at a time, so
you cant check the notices until you have fetched the result set .. then
again notices are usually only for insert/delete/update ..
This was part of what I was trying to highlight. That and the fact that
people who use databases where these sorts of activity is NORMALLY
handled by additional SQL queries will not be looking for an 'old
fashioned' method of returning them? And people writing code for Posgres
then trying to run it on MySQL should not expect it to work anyway since
any information returned is most certainly going to be different.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Hi,
There is a patch to implements this function into PDO:
http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-notices-managment.patch
Just a quick note: This changes the ABI so it can't be done in 5.3.
johannes
Sorry but what is ABI ?
Le lundi 12 octobre 2009 à 12:50 +0200, Johannes Schlüter a écrit :
Hi,
There is a patch to implements this function into PDO:
http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-notices-managment.patchJust a quick note: This changes the ABI so it can't be done in 5.3.
johannes
2009/10/12 Samuel ROZE samuel.roze@gmail.com:
Sorry but what is ABI ?
http://en.wikipedia.org/wiki/Application_binary_interface
--
Pierre
Hi,
I'm writing here to take a point about the discussion. On one side, you
want to turn this functionality to a global function, like it is
describe into this patch and on the other side, you said that on MySQL
and Oracle we can get this notices with queries so it is not needed for
them but only for PostgreSQL.
Before continuing every development I want to make like a survey about
what I (or we) will do. Here are my proposals:
- Make this functionality only for PostgreSQL, with a "pgGetNotices"
function. - Continue development for MySQL & Oracle, with the known that if
notices recuperation is enabled, PDO will have to do queries. - Let development at this stage waiting that somebody else propose a
notices patch for other Database than PostgreSQL.
Note: For MySQL there'is the mysql_info function
(http://dev.mysql.com/doc/refman/5.1/en/mysql-info.html)
Thanks a lot for your reply.
Samuel.
Le jeudi 08 octobre 2009 à 23:51 +0200, Samuel ROZE a écrit :
Hi,
I've make a patch which insert notices concepts to PDO. It create:
- PDO::noticeInfo() - to be like errorInfo
- PDO::ATTR_LOG_NOTICES, the name of the PDO parameter
- PDO::NOTICES_FETCH - fetch notices
- PDO::NOTICES_NONE - don't fetch notices
The notices HashTable is emptied at each queries.
There is a patch to implements this function into PDO:
http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-notices-managment.patchAnd one other to implements notices recuperation for PostgreSQL:
http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-pgsql-notices-managment.patchIt can be done for Oracle, i'm sure.
Thanks for feedbacks.
Samuel.
Hi,
I'm writing here to take a point about the discussion. On one side,
you
want to turn this functionality to a global function, like it is
describe into this patch and on the other side, you said that on MySQL
and Oracle we can get this notices with queries so it is not needed
for
them but only for PostgreSQL.Before continuing every development I want to make like a survey about
what I (or we) will do. Here are my proposals:
- Make this functionality only for PostgreSQL, with a "pgGetNotices"
function.- Continue development for MySQL & Oracle, with the known that if
notices recuperation is enabled, PDO will have to do queries.- Let development at this stage waiting that somebody else propose a
notices patch for other Database than PostgreSQL.Note: For MySQL there'is the mysql_info function
(http://dev.mysql.com/doc/refman/5.1/en/mysql-info.html)
well .. what Pierre (and me supporting him) was asking for is to
create an RFC page that details the actual sticking points with this
feature so that they can then discuss the above points more if need
be .. or we can take a vote on how to proceed. You are asking the
general community to vote on something where there is no clear
document describing the state of the discussion. Remember not
everybody reads all messages and even I am likely to have forgotten a
point raised in this thread by now .. and I have payed attention to
this thread from the very beginning. Writing an RFC is not about
making your life miserable .. and its not about stalling your request
either.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Here is what I expect for the notices fetching in PDO:
http://www.d-sites.com/wp-content/uploads/2009/10/RFC-PDO-Notices.pdf
Samuel.
Le lundi 12 octobre 2009 à 19:11 +0200, Lukas Kahwe Smith a écrit :
[...]
well .. what Pierre (and me supporting him) was asking for is to
create an RFC page that details the actual sticking points with this
feature so that they can then discuss the above points more if need
be .. or we can take a vote on how to proceed. You are asking the
general community to vote on something where there is no clear
document describing the state of the discussion. Remember not
everybody reads all messages and even I am likely to have forgotten a
point raised in this thread by now .. and I have payed attention to
this thread from the very beginning. Writing an RFC is not about
making your life miserable .. and its not about stalling your request
either.regards,
Lukas Kahwe Smith
mls@pooteeweet.org
hi Samuel,
May I ask you to do it in the wiki? We have a dedicated section there:
Cheers,
Here is what I expect for the notices fetching in PDO:
http://www.d-sites.com/wp-content/uploads/2009/10/RFC-PDO-Notices.pdfSamuel.
Le lundi 12 octobre 2009 à 19:11 +0200, Lukas Kahwe Smith a écrit :
[...]well .. what Pierre (and me supporting him) was asking for is to
create an RFC page that details the actual sticking points with this
feature so that they can then discuss the above points more if need
be .. or we can take a vote on how to proceed. You are asking the
general community to vote on something where there is no clear
document describing the state of the discussion. Remember not
everybody reads all messages and even I am likely to have forgotten a
point raised in this thread by now .. and I have payed attention to
this thread from the very beginning. Writing an RFC is not about
making your life miserable .. and its not about stalling your request
either.regards,
Lukas Kahwe Smith
mls@pooteeweet.org--
--
Pierre
http://wiki.php.net/rfc/pdonotices
Samuel.
2009/10/12 Samuel ROZE samuel.roze@gmail.com:
Here is what I expect for the notices fetching in PDO:
http://www.d-sites.com/wp-content/uploads/2009/10/RFC-PDO-Notices.pdfSamuel.
Le lundi 12 octobre 2009 à 19:11 +0200, Lukas Kahwe Smith a écrit :
[...]well .. what Pierre (and me supporting him) was asking for is to
create an RFC page that details the actual sticking points with this
feature so that they can then discuss the above points more if need
be .. or we can take a vote on how to proceed. You are asking the
general community to vote on something where there is no clear
document describing the state of the discussion. Remember not
everybody reads all messages and even I am likely to have forgotten a
point raised in this thread by now .. and I have payed attention to
this thread from the very beginning. Writing an RFC is not about
making your life miserable .. and its not about stalling your request
either.regards,
Lukas Kahwe Smith
mls@pooteeweet.org
I assume that calling noticeInfo() will also purge all currently
stored notices (maybe controllable via some parameter)?
For MySQL we would have to throw an error/exception in case there is a
result set open on the same connection.
I still believe that it makes sense to add this functionality.
Without it we would have to add database specific solutions for
various drivers. PostgreSQL being the obvious one, but even for MySQL
it would make sense to then at least expose the warning count etc.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Le jeudi 15 octobre 2009 à 11:08 +0200, Lukas Kahwe Smith a écrit :
I assume that calling noticeInfo() will also purge all currently
stored notices (maybe controllable via some parameter)?
If purge all notices, without parameter, like errorInfo.
For MySQL we would have to throw an error/exception in case there is a
result set open on the same connection.
Is it really impossible to query Database if there is another result set
opened ? If there's a result set opened seems that there's another query
in the same time with the same code ? Is it possible ? I don't think
so...
I still believe that it makes sense to add this functionality.
Without it we would have to add database specific solutions for
various drivers. PostgreSQL being the obvious one, but even for MySQL
it would make sense to then at least expose the warning count etc.
I still believe into it too ! I'll work about if I've more replies about
the RFC. I have got any other replies...
Samuel.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Le jeudi 15 octobre 2009 à 11:08 +0200, Lukas Kahwe Smith a écrit :
I assume that calling noticeInfo() will also purge all currently
stored notices (maybe controllable via some parameter)?If purge all notices, without parameter, like errorInfo.
For MySQL we would have to throw an error/exception in case there
is a
result set open on the same connection.Is it really impossible to query Database if there is another result
set
opened ? If there's a result set opened seems that there's another
query
in the same time with the same code ? Is it possible ? I don't think
so...
yeah .. thats just how it is in MySQL. the warnings are stored in the
connection so even opening a second connection to be able to execute
another query isnt going to help at all.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Samuel ROZE wrote:
http://wiki.php.net/rfc/pdonotices
Samuel.
The new interface combines system generated error messages with user
generated messages.
The original PostgreSQL example I saw seemed to use arbitrary text
messages, similar to Oracle's DBMS_OUTPUT (page 181 of
http://tinyurl.com/UGPOM). The MySQL examples in the RFC are seem to
be similar to Oracle's compilation warnings (page 167 of
http://tinyurl.com/UGPOM).
I think two message types should be handled separately.
Chris
--
Blog: http://blogs.oracle.com/opal
Twitter: http://twitter.com/ghrd
Folks:
The actual URI for that is
http://www.oracle.com/technology/tech/php/pdf
/underground-php-oracle-manual.pdf.
I encourage people to reconsider widespread use of URI shortening
services. They lose any clues readers may want as to what the resource
is and reduce the value of mailing list archives when the alias gets
deleted.
I hope this posting will just serve as food for thought rather than bait
for trolling a whole thread that wastes everyone's time.
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Hi Christopher,
2009/10/19 Christopher Jones christopher.jones@oracle.com:
The new interface combines system generated error messages with user
generated messages.
I think you're talking about Oracle.
The original PostgreSQL example I saw seemed to use arbitrary text
messages, similar to Oracle's DBMS_OUTPUT (page 181 of
http://tinyurl.com/UGPOM).
Page 191, this document explain how DBMS_OUTPUT raise informations,
which can be got with the RFC's method.
The MySQL examples in the RFC are seem to
be similar to Oracle's compilation warnings (page 167 of
http://tinyurl.com/UGPOM).
Page 177 there's a "PL/SQL Success With Information Warnings"
paragraph. It talks about warning raised only by the Oracle system.
It is like MySQL, you're true. The problem is that are you really
wanted this warning ? I think that yes because it helps to debug, like
others warning in MySQL and PostgreSQL.
I think two message types should be handled separately.
Why not... But the problem is that execution time will increase
because we'll have to exec two queries ! Why not because if we do
that, we have to change the PDO::ATTR_LOG_NOTICES param. I don't
really agree to that. Why not developp a Oracle function which will
returns a compilation of these warnings ? It must be better !
Moreover, theses warnings / notices seens to be equal... Why
differents methods to get them ?
Regards,
Samuel.