db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oystein.Grov...@sun.com (Øystein Grøvlen)
Subject Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
Date Tue, 07 Jun 2005 11:25:42 GMT

>>>>> "DVC" == David Van Couvering <David.Vancouvering@Sun.COM> writes:

    DVC> Thanks for this very careful review, Oystein.  Responses below.
    DVC> Øystein Grøvlen wrote:

    >> - Why do you want to write something in
    >> TestUtil.checkUniqueToString?  It just creates a lot of hazzle
    >> to have to sed this from the tests.  If I were to write a test
    >> that needed to check that strings were not equal, I think I
    >> would make my on method instead of reusing this method in order
    >> not to have to worry about "sedding".  (I also think
    >> ...NotEqual.. is a more descriptive name than ...Unique... for
    >> this method.)

    DVC> I wanted to test  both that they were not equal, and  I wanted to make
    DVC> sure the  output format  was correct. If  the sed doesn't  work, that
    DVC> means the  format is incorrect, and then  I can look at  the output to
    DVC> see what  went wrong. Just checking  to make sure  they weren't equal
    DVC> without ensuring  the format was right  made me nervous.  I suppose I
    DVC> was lazy  in that I  could have written  a routine that  validated the
    DVC> format rather  than using the master  output file mechanism  to do the
    DVC> heavy lifting for me.

But except from the explicit output from TestUtil.checkUniqueToString
your sed matches everything to the end of line.  I do not see how you
can verify any format that way.

    DVC> BTW,  I  created  TestUtil.checkUniqueToString,  I'm  not  reusing  an
    DVC> existing method.

I think you must misunderstood what I meant here.  I guess the reason
for having checkUniqueString as part of TestUtil is that is is a
general utility function that could be used by other tests.  I think
its output make it less usable for other tests.  I also think the name
is not very describing since the only thing the function does is to
test whether the output of toString for two input objects are equal or

    >> - The tests now test that the Ids of two connections are not
    >> equal.  However, for all possible bugs giving a non-unique id, I
    >> would think that only a very few would give equal ids to two
    >> connections opened in sequence.  Would it not be better to check
    >> against all currently open connections?

    DVC> I was actually checking for  the most common bug, where you're reusing
    DVC> the same id over and over again.

    DVC> I think if you want to be  picky, what you really want is to make sure
    DVC> that any given string doesn't match any other string that has occurred
    DVC> thus  far.  I should  keep  a  hashtable  of all  connection  strings
    DVC> obtained and  each time I  test I make  sure it's not in  the existing
    DVC> hash table and then add it.  I can create this test.

I think that is the ideal solution.  However, I am not sure how much
effort one should put into testing this.  I guess it is really the
responsibility of the implementor of UUID to test this, not all the
classes that uses UUID.


View raw message