Re: PreparedStatement parameters and mutable objects

Oliver,

I think finding the "offical" word on this is going to be unlikely, at
best it will be someone's opinion. It's not in the spec so it will be an
interpretation. I think more important is meeting the expected behaviour
from the users POV.

That being said, my example showing mutable objects and the expected
behaviour was just that an example, I think the behaviour should be the
same for mutable/un-mutable objects. I would expect there would be a
population of programmers out there that isn't even aware of the fact
that some objects are un-mutable/mutable. Unfortunately we need to code
to the lowest common denominator.

Dave

On Sun, 2004-01-11 at 19:49, Oliver Jowett wrote:
> Kris Jurka wrote:
> > On Mon, 12 Jan 2004, Oliver Jowett wrote:
> >
> >
> >>I'm still in favour of an "undefined behaviour" interpretation here.
> >>There's not much benefit to application code in nailing down one
> >>behaviour or the other, and leaving it undefined gives the driver the
> >>flexibility to do whichever is a better implementation for the DB in
> >>question.
> >>
> >
> >
> > The question that has yet been unanswered is how much taking advantage of
> > the "undefined behavior" will get us.  You personally seem most interested
> > in the setBytes() case because it is relevent to your application and it
> > can potentially be quite large.  I don't know how much this would gain on
> > say a Date object.  For your particular problem it seems you could simply
> > wrap the byte array in question inside a ByteArrayInputStream (which does
> > not copy it) and use setBinaryStream which would allow the delayed reading
> > of it.
>
> Yeah, modifying the driver to support setBinaryStream better is my
> second choice (the current implementation just delegates to setBytes).
> Most of that work overlaps with setBytes() though, it'll be almost as
> easy to do both. And wrapping the array just to have the driver unwrap
> it again seems a bit perverse :)
>
> I'm interested in the official word on this anyway since even if it's
> not useful to implement for some types, it's still a correctness issue.
>
> -O
>
--
Dave Cramer
519 939 0336
ICQ # 1467551