You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Shreyas Kaushik (JIRA)" <de...@db.apache.org> on 2005/01/10 13:42:13 UTC
[jira] Commented: (DERBY-105) drop table statement shows wrong message after dropping table
[ http://issues.apache.org/jira/browse/DERBY-105?page=comments#action_57463 ]
Shreyas Kaushik commented on DERBY-105:
---------------------------------------
One possible solution for this:
In the file JDBCDisplayUtil.java, the method
static void DisplayUpdateCount(PrintWriter out, int count, int indentLevel ) is the place where the messsages are displayed. Here we can replace the condition
if( count >= 0 )
with
if( count > 0 )
This will cause the message "Statement executed" to be displayed. If there are any warning messages those are displayed afetr this. This seems more meaningful as it says statement issued was executed ( warnings if an y will be displayed ).
But doing this change will also require changes in all *.out files in the "master" directory for tests which are written using the previous message.
Please comment.
> drop table statement shows wrong message after dropping table
> -------------------------------------------------------------
>
> Key: DERBY-105
> URL: http://issues.apache.org/jira/browse/DERBY-105
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.0.2.2
> Environment: generic
> Reporter: Amit Handa
> Priority: Minor
>
> If we drop a table using the ij tool,
> it returns a message that "0 rows inserted/updated/deleted"
> giving an impression as if the table is still there and some update has been done
> (as if executed a DML statement) to the table, whereas this is not the case.
> Note that the same message appears while we execute a DML(insert/update/delete) query on the table.
> which further confuses the user as if a table hasn't been dropped and updations still happenning
> on the table instead of dropping(and creating)
> The same is the case when a table is created.
> Rather it when a table is created
> ij> create table temp(cv char(10));
> 0 rows inserted/updated/deleted <-- Wrong message
> ij> select * from temp;
> CV
> ----------
> 0 rows selected
> ij> insert into temp values('a');
> 1 row inserted/updated/deleted
> ij> drop table temp;
> 0 rows inserted/updated/deleted <-- Wrong message
> ij>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-105) drop table statement shows wrong
message after dropping table
Posted by Daniel John Debrunner <dj...@debrunners.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
RPost wrote:
> Won't that also display the message "Statement executed" for an
> insert/update/delete that affects 0 rows? That would mean that, for
example,
> an insert affecting 0 rows would not tell the user that 0 rows were
affected
> but only that the statement executed. Since inserts (et al) are much more
> frequent than create/drop statements the cure may be worse than the
disease.
>
> I don't know if there is a way to tell what type of statement
> (insert/update/delete/create/drop/other?) was being executed.
There is (or maybe, might be), a statement execution can return either
an update count, a ResultSet or 'no result'. I think DDL should return
'no result' and my guess is there are really one or two bugs ...
1) Derby does not correctly return 'no result' for DDL.
and/or
2) ij does not look handle 'no result' from a Statement execution.
The issue is for a simple execution that does not return multiple
results, ie not a procedure call, what is the correct way of detecting
the 'no result' state?
java.sql.Statement.executeUpdate(String sql) will return 0 (as
documented in the javadoc), but what call(s) needs to be made after that
to determine the difference between '0 update count' and 'no result'?
(and similar for Statement.execute() and PreparedStatement execute calls)
Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFB4urqIv0S4qsbfuQRAoDkAJ9IllJmirkeEMuny/qLxZDIwEWiKgCgiJsh
bpdroTugYaMuzPHRhDxcXg4=
=0Y0b
-----END PGP SIGNATURE-----
Re: [jira] Commented: (DERBY-105) drop table statement shows wrong message after dropping table
Posted by RPost <rp...@pacbell.net>.
Won't that also display the message "Statement executed" for an
insert/update/delete that affects 0 rows? That would mean that, for example,
an insert affecting 0 rows would not tell the user that 0 rows were affected
but only that the statement executed. Since inserts (et al) are much more
frequent than create/drop statements the cure may be worse than the disease.
I don't know if there is a way to tell what type of statement
(insert/update/delete/create/drop/other?) was being executed.
----- Original Message -----
From: "Shreyas Kaushik (JIRA)" <de...@db.apache.org>
To: <de...@db.apache.org>
Sent: Monday, January 10, 2005 4:42 AM
Subject: [jira] Commented: (DERBY-105) drop table statement shows wrong
message after dropping table
> [
http://issues.apache.org/jira/browse/DERBY-105?page=comments#action_57463 ]
>
> Shreyas Kaushik commented on DERBY-105:
> ---------------------------------------
>
> One possible solution for this:
>
> In the file JDBCDisplayUtil.java, the method
>
> static void DisplayUpdateCount(PrintWriter out, int count, int
indentLevel ) is the place where the messsages are displayed. Here we can
replace the condition
>
> if( count >= 0 )
>
> with
>
> if( count > 0 )
>
> This will cause the message "Statement executed" to be displayed. If
there are any warning messages those are displayed afetr this. This seems
more meaningful as it says statement issued was executed ( warnings if an y
will be displayed ).
>
> But doing this change will also require changes in all *.out files in the
"master" directory for tests which are written using the previous message.
>
> Please comment.
>
> > drop table statement shows wrong message after dropping table
> > -------------------------------------------------------------
> >
> > Key: DERBY-105
> > URL: http://issues.apache.org/jira/browse/DERBY-105
> > Project: Derby
> > Type: Bug
> > Components: SQL
> > Versions: 10.0.2.2
> > Environment: generic
> > Reporter: Amit Handa
> > Priority: Minor
>
> >
> > If we drop a table using the ij tool,
> > it returns a message that "0 rows inserted/updated/deleted"
> > giving an impression as if the table is still there and some update has
been done
> > (as if executed a DML statement) to the table, whereas this is not the
case.
> > Note that the same message appears while we execute a
DML(insert/update/delete) query on the table.
> > which further confuses the user as if a table hasn't been dropped and
updations still happenning
> > on the table instead of dropping(and creating)
> > The same is the case when a table is created.
> > Rather it when a table is created
> > ij> create table temp(cv char(10));
> > 0 rows inserted/updated/deleted <-- Wrong message
> > ij> select * from temp;
> > CV
> > ----------
> > 0 rows selected
> > ij> insert into temp values('a');
> > 1 row inserted/updated/deleted
> > ij> drop table temp;
> > 0 rows inserted/updated/deleted <-- Wrong message
> > ij>
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> If you want more information on JIRA, or have a bug to report see:
> http://www.atlassian.com/software/jira
>
Re: [jira] Commented: (DERBY-105) drop table statement shows wrong
message after dropping table
Posted by myrnap <my...@Golux.Com>.
Shreyas Kaushik (JIRA) wrote:
>But doing this change will also require changes in all *.out files in the "master" directory for tests which are written using the previous message.
>
>Please comment.
>
>
If the community thinks this is the right thing to do, then of course
the output of the tests should not stop us. If that's decided, maybe one
of the committers can work on doing a mass update, so we don't all get a
huge patch.
Myrna