Daniel John Debrunner wrote:
Andreas Korneliussen wrote:
I am a bit curious about the statement about improving the JDBC
updatable result set implementation to not use positioned updates.
Did you mean that an improvement could be to not base JDBC updatable
resultsets on positioned updates at all, and instead invent another
mechanism. If so, do you have any specific ideas on this ?
It was just a vague idea. It seems somewhat inefficient for an updatable
ResultSet to create a SQL statement, have that parsed & compiled in
order to perfom an update or delete etc. However, the use of SQL is a
great example of re-use, especially as the problem looks simple 'update
the current row', but in fact is complicated. The update must determine
which triggers are to be invoked, which constraints to be checked etc.
etc. This of course is handled automatically through the use of SQL.
Maybe, just maybe, the code could be re-factored to allow updateable
ResultSets to avoid the SQL parsing step but that's the limit of what
I've thought about.
We are thinking of coninuing using positioned updates when doing
scrollable updatable resultsets - that is why I am asking.
You should continue on your current path. I'm not working on this at all.
The general point I was trying to make it that testing user visible
functionality implictly due to implementation knowledge is not a good
practice. Test as we intend the users to use it, not indirectly through
a different mechanism that might effect things somehow.
I agree with this point - thanks for the clarifications.
-- Andreas
