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
not.

    >> - 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.

-- 
Øystein


Mime
View raw message