Re: DERBY-6802 status

[Bryan Pendleton <bp...@gmail.com>]

>     Yes, that is the right idea. I think the critical
>     code that we need to re-factor for the purpose of
>     splitting the sqlerrmc string back into the
>     arguments and messageID can be found at lines 154-186
>     of o.a.d.catalog.SystemProcedures.java in the java/engine directory.
>
>
> Do we need all the code from lines 154-186 ? or just the part that takes out the substring  "UK_APPLICATION" and "APPLICATION" from UK_APP LICATION_NAME¶APPLICATION¶23505 ?
>

I'm not 100% sure.

But looking at it now, it seems to me like the entire
body of the SQLCAMESSAGE method belongs in MessageUtils.

So SQLCAMESSAGE() would just be a wrapper around
MessageUtils.SQLCAMESSAGE(), and we'd just move all the
code for that one method from SystemProcedures.java to
MessageUtils.java.

Basically, every time I see code like:

     // This token delimiter value is used to separate the tokens for multiple
     // error messages.  This is used in DRDAConnThread
     /**
      * <code>SQLERRMC_MESSAGE_DELIMITER</code> When message argument tokes are sent,
      * this value separates the tokens for mulitiple error messages
      */
     public static final String SQLERRMC_MESSAGE_DELIMITER = new String(new char[] {(char)20,(char)20,(char)20});

that is the code that I am trying to have us re-factor and put
into MessageUtils.

The magic "delimiters" that are used by the server and client
code to pack the error messages into the network protocol
message are the things that are causing us all the problems
with DERBY-6773.

Right now, that code is scattered all about the engine, and can't
be used by the client, and that's the essential problem in DERBY-6773.

So one way to state the goal is:

	When we're done, the magic constants

		SQLERRMC_MESSAGE_DELIMITER
		SQLERRMC_TOKEN_DELIMETER
	and	DB2_JCC_MAX_EXCEPTION_PARAM_LENGTH

	should exist *only* in MessageUtils.java, and should be
	private variables in that class.

	And every other place that currently uses those variables,
	should be changed to call the functions in MessageUtils instead.

At that point, MessageUtils will be the *only* class in the Derby source
code which knows how exceptions are packed and unpacked in network
messages, instead of the 10 or so classes that currently have such code.

And since MessageUtils will also be available to the client code, we'll
be able to unpack the exception arguments and use them to create the
instance of DerbySQLIntegrityConstraintViolaationException.

Which is our ultimate goal.

:)

thanks,

bryan