Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4371DC78.3030102@debrunners.com>
Date: Wed, 09 Nov 2005 12:24:40 +0100
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: [jira] Updated: (DERBY-231) "FOR UPDATE" required for updatable
 result set to work
References: <1423548905.1113999264585.JavaMail.jira@ajax.apache.org>
 <1821373379.1130947796422.JavaMail.jira@ajax.apache.org>
 <20051103001306.GB5919@barbar.sun.com> <436951E6.7000701@debrunners.com>
 <436A1825.2000708@sun.com> <436A81A7.20107@debrunners.com>
 <4371C2FB.6080601@sun.com>
In-Reply-To: <4371C2FB.6080601@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.