Re: Proposal for new $h->{ReadOnly} attribute

On Mon, 30 Apr 2007 14:56:37 +0100, Tim Bunce wrote:

> I've just added this to the DBI docs:
>
> =item C (boolean, inherited)
>
> An application can set the C attribute of a handle to a true value to
> indicate that it will not be attempting to make any changes (insert, delete,
> update etc) using that handle or any children of it.
>
> If the driver can make the handle truely read-only (by issing a statement like

s/issing/issuing/ ?

> "C" as needed, for example) then it should.
> Otherwise the attribute is simply advisory.
>
> A driver can set the C attribute itself to indicate that the data it
> is connected to cannot be changed for some reason.
>
> Library modules and proxy drivers can use the attribute to influence their behavior.
> For example, the DBD::Gofer driver considers the C attribute when
> making a decison about whether to retry an operation that failed.
>
> =cut

Is it inherited? Do statement handles from a ReadOnly driver handle get
the same attribute passed? If so: useful.
I'd like to see that extended to be able to allow dirty reads or no-lock
reads, whatever the database allows.

--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.0 & 10.2, AIX 4.3 & 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/

Re: Proposal for new $h->{ReadOnly} attribute

On Tue, May 01, 2007 at 10:43:40AM +0200, H.Merijn Brand wrote:
> On Mon, 30 Apr 2007 14:56:37 +0100, Tim Bunce wrote:
>
> > I've just added this to the DBI docs:
> >
> > =item C (boolean, inherited)
> >
> > An application can set the C attribute of a handle to a true value to
> > indicate that it will not be attempting to make any changes (insert, delete,
> > update etc) using that handle or any children of it.
> >
> > If the driver can make the handle truely read-only (by issing a statement like
>
> s/issing/issuing/ ?

Yes, and s/truely/truly/ :)

> > "C" as needed, for example) then it should.
> > Otherwise the attribute is simply advisory.
> >
> > A driver can set the C attribute itself to indicate that the data it
> > is connected to cannot be changed for some reason.
> >
> > Library modules and proxy drivers can use the attribute to influence their behavior.
> > For example, the DBD::Gofer driver considers the C attribute when
> > making a decison about whether to retry an operation that failed.
> >
> > =cut
>
> Is it inherited?

Yeap.

> Do statement handles from a ReadOnly driver handle get
> the same attribute passed? If so: useful.

> I'd like to see that extended to be able to allow dirty reads or no-lock
> reads, whatever the database allows.

Those are too database specific to warrant adding to the DBI (and not
really related to to the role of the ReadOnly attribute). Drivers can
always offer private ways to do such things.

Tim.

Fwd: Proposal for new $h->{ReadOnly} attribute

------=_Part_174540_14255543.1178026448804
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Ooops; most of the mailing lists I work with redirect responses to the
list. I forget this one doesn't.

---------- Forwarded message ----------
From: Jonathan Leffler
Date: May 1, 2007 6:32 AM
Subject: Re: Proposal for new $h->{ReadOnly} attribute
To: "H.Merijn Brand"



On 5/1/07, H.Merijn Brand wrote:
>
> On Mon, 30 Apr 2007 14:56:37 +0100, Tim Bunce wrote:
>
> > I've just added this to the DBI docs:
> >
> > =item C (boolean, inherited)
> > [...]
> > =cut
>
> I'd like to see that extended to be able to allow dirty reads or no-lock
> reads, whatever the database allows.


It seems to me that the set of permitted statements will be somewhat
specific to the DBMS. I'd expect 'session attributes' to be OK; things like
isolation level and even locking tables should be allowed - as long as the
session doesn't alter the database.


A complex question - probably one to which there isn't an answer - relates
to 'when is an operation read-only'?

Clearly, an INSERT statement is not allowed; ditto UPDATE or DELETE. Also,
DDL statements like CREATE TABLE are not allowed.

But what about a statement that creates a temporary table - only accessible
to the session, only for the duration of the session?
SELECT * FROM SomeTable INTO TEMP NewTable;
Is that supposed to be allowed in a read-only transaction/session? The code
would not allow the corresponding DROP TABLE (or DELETE), so you could only
create the table once and reuse it.

Even more complex - what about executing procedures. Can you trust the
procedure to make no modifications? Unless the system can tell you that the
procedure is 'safe',

I have a program, SQLCMD, for which I recently added (at user request) a new
SQLREAD program (a minor subset of the main program). It had to deal with
these issues: which statements to really allow, stored procedures, and
SELECT INTO TEMP. And I ended up allowing non-modifying statements, the
implicit temporary tables created by SELECT INTO TEMP, and rejecting direct
execution of stored procedures.



--
Jonathan Leffler #include
Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."

--
Jonathan Leffler #include
Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."

------=_Part_174540_14255543.1178026448804--