Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Mon, 07 Nov 2005 09:56:45 +0100
From: "Bernt M. Johnsen" <Bernt.Johnsen@Sun.COM>
Subject: Re: [jira] Updated: (DERBY-231) "FOR UPDATE" required for updatable
 result set to work
In-reply-to: <436BA88E.1020903@debrunners.com>
To: derby-dev@db.apache.org
Message-id: <20051107085645.GB7076@atum01.norway.sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary=nVMJ2NtxeReIH9PS
Content-disposition: inline
User-Agent: Mutt/1.5.10i
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> <436A5A76.2000706@debrunners.com>
 <20051103223528.GA6087@barbar.sun.com> <436AD2E6.9070108@debrunners.com>
 <20051104091550.GB21210@atum01.norway.sun.com>
 <436BA88E.1020903@debrunners.com>


--nVMJ2NtxeReIH9PS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

>>>>>>>>>>>> Daniel John Debrunner wrote (2005-11-04 10:29:34):
> That's the leap of faith I have trouble with. The assumption that the
> read only of the result set means read only status of the SQL query.

>=20
> I see the ResultSet.CONCUR_READ_ONLY only applying to the client side
> ResultSet, because that's what it is declared to mean.
>=20
> public static final int CONCUR_READ_ONLY
>=20
>     The constant indicating the concurrency mode for a ResultSet object
> that may NOT be updated.
>=20
> And we have instances where we know the ResultSet being read only does
> not make the SQL query read only, when the select includes the FOR
> UPDATE.

I would claim that the statement above implies that CONCUR_UPDATABLE
also only applies to the client side, and thus "FOR UPDATE" should be
required to be able to update the underlying table. And that's not
what we want (and not what this patch is implementing).

I believe that one has to view ResultSets in the context of an SQL
cursor to make sense of this. Updatability, holdability and
scrollability are issues only in a cursor context in the SQL
standards.

Well, "Leap of faith" is maybe a good description of this discussion
which is becoming kind of philosophical. Perhaps we should continue
this discussion over a beer at ApacheCon?

--=20
Bernt Marius Johnsen, Database Technology Group,=20
Sun Microsystems, Trondheim, Norway

--nVMJ2NtxeReIH9PS
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDbxbNlFBD9TXBAPARAoTvAKDT25lGmak1GD1/itijCBLdrldUIACeOkbe
zUoser3dAnEKCu+FdBOlISg=
=aK0f
-----END PGP SIGNATURE-----

--nVMJ2NtxeReIH9PS--