Re: PreparedStatement parameters and mutable objects

Andrew,

What happens in Oracle if he second setBytes is not called?
does it still insert {1,2,33} ?

I think my biggest concern is Andrew's last statement:
"Ambiguity tends to have to favor the idiot, unfortunately"


Dave

On Fri, 2004-01-09 at 09:28, Andrew Rawnsley wrote:
> If anyone is looking for behavior from others, Oracle (my apologies for
> using the 'O' word...) behaves like this:
>
>         byte[] b = new byte[] {(byte)1,(byte)2,(byte)3};
>         stmnt.setBytes(1,b);
>         b[2] = (byte) 33;
>         stmnt.setBytes(1,b);
>         stmnt.execute();
>
> results in {1,2,33}. (Disclaimer - I'm not advocating something just
> because 'Oracle does it this way')
>
> Why someone would do this is, of course, I don't know.
>
> While I am all for the idea of improved performance, I find myself
> forced to agree with the idea that, while something
> like the above is kooky, it isn't illegal, and falls into the realm of
> expected (but not necessarily mandated) behavior from a driver.
> Ambiguity tends to have to favor the idiot, unfortunately.
>
> On Jan 9, 2004, at 8:46 AM, Dave Cramer wrote:
>
> > Well there is some hint that this is incorrect:
> >
> >
> > pstmnt = con.prepareStatment("insert into foo values(?,?)");
> >
> > pstmnt.setString(1,"abcd");
> >
> > for( i=0; i< 5; i++)
> > {
> >     Integer intx = new Integer(i);
> >     pstmnt.setInt(2,intx)
> >     pstmnt.executeUpdate();
> > }
> >
> > The above code should insert ("abcd", 0 .. 4 ) into five rows
> >
> > The point being that the value for setXXX does not change until setXXX
> > is called.
> >
> > This is from section 24.1.2 in the JDBC api tutorial
> >
> > In all I'm sort of sitting on the fence here. I guess we could try it
> > and see how many people get tripped up?
> >
> > Dave
> >
> > On Fri, 2004-01-09 at 03:18, Kris Jurka wrote:
> >> On Fri, 9 Jan 2004, Oliver Jowett wrote:
> >>
> >>>> I'm saying that doing it this way will likely expose buggy code,
> >>>> which
> >>>> we will end up having to figure out why it doesn't work, when the
> >>>> user
> >>>> says "my code used to work, and now it doesn't", plus they don't
> >>>> send us
> >>>> code to look at.
> >>>
> >>> How far do we go to support buggy code though? If we can't make this
> >>> sort of change, we lose several opportunities for optimization.
> >>
> >> I don't think you can label this as buggy code unless you can point
> >> to the
> >> spec and say where it is disallowed.  It is certainly something that
> >> looks
> >> dangerous and is unlikely to be written by the average developer, but
> >> that
> >> doesn't make it illegal.  I lean towards the notion that when I say
> >> setXXX
> >> that's the time the value must be saved because that's certainly more
> >> intuitive and specific than "sometime later when the driver decides
> >> to."
> >>
> >> Kris Jurka
> >>
> >>
> >> ---------------------------(end of
> >> broadcast)---------------------------
> >> TIP 4: Don't 'kill -9' the postmaster
> >>
> > --
> > Dave Cramer
> > 519 939 0336
> > ICQ # 1467551
> >
> >
> > ---------------------------(end of
> > broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> >                http://www.postgresql.org/docs/faqs/FAQ.html
> >
> --------------------
>
> Andrew Rawnsley
> President
> The Ravensfield Digital Resource Group, Ltd.
> (740) 587-0114
> www.ravensfield.com
>
--
Dave Cramer
519 939 0336
ICQ # 1467551