db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre.Tjeldv...@Sun.COM
Subject Re: [jira] Commented: (DERBY-85) NPE when creating a trigger on a table and default schema doesn't exist.
Date Sat, 11 Feb 2006 15:11:10 GMT
>>>>> "SB" == Satheesh Bandaram <satheesh@Sourcery.Org> writes:

    SB> Dyre.Tjeldvoll@Sun.COM wrote:

    SB>                         "KAH" == Knut Anders Hatlen <Knut.Hatlen@Sun.COM>

    SB>     Hmm, I just discovered, to my surprise and disappointment, that I
    SB>     am unable to test that this actually works, because
    SB>     lang/triggerGeneral.sql does not run under DerbyNet or DerbyNetClient.
    SB>     Why is that? I assumed, in my naivete, that tests should run in
    SB>     all three frameworks, unless the test is testing something that is specific
    SB>     to a particular framework... 

    SB> This is the general rule... For tests that verify pure SQL
    SB> behavior, the framework shouldn't matter. Many of the
    SB> derbyLang tests are meant to test just SQL behavior, so many
    SB> just run in embedded framework only. Running these tests in
    SB> other frameworks might generate different outputs so may have
    SB> to generate different masters. Is there a reason why you would
    SB> like your new test to run in all frameworks?

Not really. I just wanted to verify that the
specify-part-of-the-connection-url trick gave me a new and
valid connection even in a different framework.

    SB> It seems the behavior is likely to be the same if you
    SB> specify a userName in the URL.

I would hope so.

    SB> Looking at 'suites' directory is one way. You could also
    SB> invoke the tests without actually running them and then see if
    SB> your test gets picked up in the framework of your
    SB> interest. RunTest has listOnly option.

Sure, that would work. My problem was that after modifying
triggerGeneral.sql I ran it in embedded, and then in DerbyNet and
DerbyNetClient. It worked fine in embedded but failed with in the two
other frameworks. If I had looked at the suites I would have found out
that this particular test is not run with those frameworks. But I
still wasn't sure if the failure was caused by the change that I made, or
if it would have failed anyway. 

When running the test I only saw the last part of the diff in my
terminal window. And there I saw the text that I had just added
to the test script, so naturally I assumed that I had broken something.

As it happens I hadn't, but if the test actually had been working in
all frameowks before (even if it wasn't mentioned in the Net-suites),
I would not want to be the one who broke it. That's reasonable isn't
it?  Or am I just being paranoid? :)


View raw message