Re: ALIAS as CHECK constraint on DOMAIN fails at second DB startup

14 views
Skip to first unread message

Noel Grandin

unread,
Oct 25, 2012, 5:08:44 AM10/25/12
to h2-da...@googlegroups.com, Ben Gardener

On 2012-10-24 14:18, Ben Gardener wrote:
> A userdefined function MYFUNC(VALUE), bound to a DOMAIN
> CHECK(MYFUNC(VALUE))
> does not work from second DB start onwards.
> Reason: The DB reloads meta data by a fixed ordering where FUNCTIONS
> loaded after DOMAINS.
> This results in a "FUNCTION not found" exception when recreating the
> DOMAIN.

Do you have a small self-contained test case for this?
Because we have a unit test in
TestCases#testCheckConstraintWithFunction() which tests this very
situation, and it seems to be working for me.

Or maybe you are running an older version?

Ben Gardener

unread,
Oct 25, 2012, 8:08:14 AM10/25/12
to h2-da...@googlegroups.com, Ben Gardener

I don't have a simple testcase available, but you can look into Database.open() at those lines:

        Collections.sort(records);
        for (MetaRecord rec : records)
        {
            rec.execute(this, systemSession, eventListener);
        }

Original MetaRecord code sorts object types by a fixed order with USER_DATATYPE first, then USER_FUNCTION. This is wrong in cases where the DOMAIN references an ALIAS.
It must result in a missing function dependency when resolving the DOMAIN, because no functions available at that time.
There is no problem in the DOMAIN/ALIAS defining session. After reopening the DB internal ordering takes place with mentioned dependency problem.


Noel Grandin

unread,
Oct 25, 2012, 8:23:07 AM10/25/12
to h2-da...@googlegroups.com, Ben Gardener

On 2012-10-25 14:08, Ben Gardener wrote:
>
> I don't have a simple testcase available, but you can look into
> Database.open() at those lines:
>
> Collections.sort(records);
> for (MetaRecord rec : records)
> {
> rec.execute(this, systemSession, eventListener);
> }
>

We appear to have changed that sort-order at some point in time, so that
USER_FUNCTION sorts before USER_DATATYPE.

Specifically, we fixed this problem on the 17th of October in 2010 in
SVN revision 3010.

So you are running a version that is more than 2 years out of date.

So, by ignoring my question about what version you are running, you have
wasted my time.
Which I am providing free of charge, by the way.
What do you think your odds are of me answering any of your future
questions?

Reply all
Reply to author
Forward
0 new messages