You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Kathey Marsden <km...@sbcglobal.net> on 2005/06/21 21:28:22 UTC
The new connection toString()
I received this feedback on our new connection toString() output. I
personally am not a big fan of the integer by itself either but thought
I was being picky after a long discussion.
I noticed a problem that the toString() of the connection returns an
integer for the connection (e.g. 1)
Sample output is:
the xaconnection is: 0
the xaconnection1 is: 1
the connection is: 1
the second is: 2
as you see its numbers, without any mention of the object type itself,
this will make problems very difficult to debug.
Thoughts?
Kathey
Re: The new connection toString()
Posted by David Van Couvering <Da...@Sun.COM>.
Thanks for helping out with this, Kathey. I am in no rush to do another
patch for this, next week is fine. I'll be busy at JavaOne all next
week anyway...
David
Kathey Marsden wrote:
> David Van Couvering wrote:
>
>
>>Sigh... The problem is there are two uses for this output. One is
>>for human-readability of Connection.toString(), and one is for
>>correlating the connection string with the SESSID/LCCID in the error log.
>>
>>When just looking at it from the point of view of the first usage, the
>>simple integer looks unhelpful. Looking at it from the point of view
>>of the second usage, having the class name in there makes it harder to
>>do the correlation. For example, you couldn't just do (in pseudocode):
>>
>>SELECT * FROM ErrorLogVTI where SESSID=conn.toString()
>>
>>IMHO, if a user needs to distinguish between class names, they can
>>easily print it out as a prefix. But I'll defer to the majority
>>opinion here.
>>
>
> My concern is that someone who didn't have the benefit of our
> conversations here wouldn't really grok that intention or the
> definition, but rather would tend to say, "Hello Mr. Integer, what do
> you mean?" That is why I was always a fan of the default toString as it
> is well defined and generally understood , but i won't go there again.
> I think you are right about the majority opinion. I will come up with
> a proposed format that is hopefully more self documenting and includes
> the SESSID and put it to vote. I don't think I'll get it out until
> next week though. Does that sound ok to you?
>
> Kathey
>
>
Re: The new connection toString()
Posted by Kathey Marsden <km...@sbcglobal.net>.
David Van Couvering wrote:
> Sigh... The problem is there are two uses for this output. One is
> for human-readability of Connection.toString(), and one is for
> correlating the connection string with the SESSID/LCCID in the error log.
>
> When just looking at it from the point of view of the first usage, the
> simple integer looks unhelpful. Looking at it from the point of view
> of the second usage, having the class name in there makes it harder to
> do the correlation. For example, you couldn't just do (in pseudocode):
>
> SELECT * FROM ErrorLogVTI where SESSID=conn.toString()
>
> IMHO, if a user needs to distinguish between class names, they can
> easily print it out as a prefix. But I'll defer to the majority
> opinion here.
>
My concern is that someone who didn't have the benefit of our
conversations here wouldn't really grok that intention or the
definition, but rather would tend to say, "Hello Mr. Integer, what do
you mean?" That is why I was always a fan of the default toString as it
is well defined and generally understood , but i won't go there again.
I think you are right about the majority opinion. I will come up with
a proposed format that is hopefully more self documenting and includes
the SESSID and put it to vote. I don't think I'll get it out until
next week though. Does that sound ok to you?
Kathey
Re: The new connection toString()
Posted by David Van Couvering <Da...@Sun.COM>.
Sigh... The problem is there are two uses for this output. One is for
human-readability of Connection.toString(), and one is for correlating
the connection string with the SESSID/LCCID in the error log.
When just looking at it from the point of view of the first usage, the
simple integer looks unhelpful. Looking at it from the point of view of
the second usage, having the class name in there makes it harder to do
the correlation. For example, you couldn't just do (in pseudocode):
SELECT * FROM ErrorLogVTI where SESSID=conn.toString()
IMHO, if a user needs to distinguish between class names, they can
easily print it out as a prefix. But I'll defer to the majority opinion
here.
David
Kathey Marsden wrote:
> I received this feedback on our new connection toString() output. I
> personally am not a big fan of the integer by itself either but thought
> I was being picky after a long discussion.
>
> I noticed a problem that the toString() of the connection returns an
> integer for the connection (e.g. 1)
> Sample output is:
>
> the xaconnection is: 0
> the xaconnection1 is: 1
> the connection is: 1
> the second is: 2
>
> as you see its numbers, without any mention of the object type itself,
> this will make problems very difficult to debug.
>
>
> Thoughts?
>
>
> Kathey
>
>