db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mamta Satoor <ma...@Remulak.Net>
Subject Re: [VOTE][PATCH]delete from the resultset using JDBC 2.0 UpdatableResultsetAPIs
Date Sun, 12 Dec 2004 16:50:36 GMT

Daniel John Debrunner wrote:

> Hash: SHA1
> Mamta Satoor wrote:
> >
> > Hi Dan,
> >
> > Thanks for taking the time to do the review. Answers to your questions
> > 1)The tutorial book says that ResultSet.rowDeleted determines whether *the
> > current row* in this ResultSet object has been deleted. Going on this
> > information, I will leave my code for rowDeleted as is. But if this seems
> > incorrect to anyone, please let me know.
> >
> > 2)As for the next set of 3 questions,
> > a)If ResultSetMetaData indicates that one/more columns are not
> nullable, then
> > what should happen to those columns when the driver is trying to make a
> > delete row hole with null values for all the columns in the row?
> > b)Where should be ResultSet positioned after a successful deleteRow call?
> > c)What should happen if deleteRow is called more than once on the same
> row?
> >
> > I haven't found anything in the JDBC docs or in the Tutorial book about
> > what a JDBC driver should do in above sceanrios. I would appreciate
> > any feedback from the community on these 3 questions.
> An alternate approach would be to return false for
> DatabaseMetaData.deletesAreDetected().
> Then:
>         1) becomes a non-issue.
>         2a) becomes a non-issue
>         2b) the result set would be positioned before the next row
>         2c) can't happen.
> I think deletesAreDetected() returning true is only useful for
> scrollable result sets, which you are not supporting. And the
> deletesAreDetected() method does take a result set type, so in the
> future scrollable results sets could support holes, while forward only
> did not.
> Any reason you selected to detect deletes?
> Dan.

Before we explore the alternative approach, here are some tidbits about the
implementation that I submitted.

The reason I chose to detect deletes is that to me, it seemed like the complete
implementation of delete rather than just saying deletes are not detected.
And, it was easy to implement :-)

I thought further about the 3 issues that we have been discussing.
2a)We can continue to make the columns that are not nullable as null but
since it is just a hole, a program should not be using the contents of the
deleted hole anyways. And the program can find out from rowDeleted
if they are on a deleted hole.

2b)Just as with positioned deletes, the ResultSet can be positioned right
before the next row (as Dan suggested in his alternative approach).

2c)In my implementation, I am letting the driver code throw an exception if the
second deleteRow is attempted on a deleted row. Rather than that, I think
it will be better to let the engine deal with the second deleteRow attempt.
Then we will get the same exception as for positioned delete. eg from Derby's
existing positioned delete support (this is what updatable resultsets rely on)
ij> -- .target cursor on already deleted row
get cursor c9 as 'select * from t1 for update';
ij> next c9;
I          |V         |D                     |T
1          |1111111111|1.1E12                |11:11:11
ij> delete from t1 where current of c9;
1 row inserted/updated/deleted
ij> delete from t1 where current of c9;
ERROR XCL08: Cursor 'C9' is not on a row.

If the community agrees to this, I can submit another patch with these changes
and others suggested by Dan for SQLState change, error message fix and test
for delete trigger.


View raw message