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. Dan.
