db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernt M. Johnsen" <Bernt.John...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-825) writeSQLCAGRP() should use byte[] constants instead of Strings where feasible
Date Fri, 20 Jan 2006 12:09:57 GMT
I have reviewed and am testing this patch. I think it is "worthy" for
committ, but I have one question:

Dyre: Do you want to pursue Bryan's proposal now or do you think we
should committ and file Bryan's propsal as a (near) future

>>>>>>>>>>>> Knut Anders Hatlen wrote (2006-01-20 09:22:28):
> Bryan Pendleton <bpendleton@amberpoint.com> writes:
> > Dyre Tjeldvoll (JIRA) wrote:
> >>> A solution is to keep the commonly used SQLStates as byte[] constants that
can be inserted into the message with writeBytes().
> >
> > I think that the solution shows great promise, but the patch
> > that you provided seems too "open coded" for me.
> >
> > It seems to me that the recently-added DRDAString class could
> > be used as the encapsulation vehicle for this String/byte[]
> > caching stuff, so that the bulk of the DRDA code didn't have
> > to be so involved in the details of when to use the string and
> > when to use the byte array.
> >
> > So instead of seeing a bunch of changes like:
> >
> > -		writer.writeString(server.prdId);
> > +        // Write the byte[] constant rather than the string, for efficiency
> > +        writer.writeBytes(server.prdIdBytes_);
> >
> > which seems to mean that we'd have to maintain constant vigilance
> > into the future to make sure that we know when to use the String
> > versus when to use the byte[], it seems like we should turn an
> > object like server.prdId into a DRDAString, and then let DDMWriter
> > and DRDAString work out the details themselves about whether to use
> > the String or the byte[].
> >
> > Does this make any sense? Am I barking up the wrong tree?
> It makes sense, but DRDAString uses a CcsidManager to convert between
> byte[] and String. Currently, the only implementation of CcsidManager
> is for ebcdic, while the message Dyre is working on is sent in UTF-8,
> I think. In that case we need a UTF8CcsidManager.
> -- 
> Knut Anders

Bernt Marius Johnsen, Database Technology Group, 
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway

View raw message