Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ISE: Self reference in computed using __source__ #5661

Closed
CarsonF opened this issue Jun 15, 2023 · 1 comment · Fixed by #5715
Closed

ISE: Self reference in computed using __source__ #5661

CarsonF opened this issue Jun 15, 2023 · 1 comment · Fixed by #5715
Assignees

Comments

@CarsonF
Copy link

CarsonF commented Jun 15, 2023

  • EdgeDB Version: 3.0-rc.2+eb06d9e
  • EdgeDB CLI Version: 3.1.3+2f81fc4
  • OS Version: OSX 13.2.1

Steps to Reproduce:

  1. start edgedb watch
  2. add
    abstract type Pinnable {
      property pinned := __source__ in <Pinnable>{};
    }
    
  3. add
    type Foo extending Pinnable {}
    
Schema migration error: InternalServerError: object type 'default::Foo' has no link or property '__type__'
@CarsonF CarsonF changed the title Extended type has no link or property '__type__' ISE: Self reference in computed using __source__ Jun 26, 2023
@elprans
Copy link
Member

elprans commented Jun 28, 2023

Also affects constraints:

module person{
    abstract type Person {
        multi link friends : Person{
            constraint expression on (
                    __subject__ != __subject__@source
                );
        };

    }

    type Employee extending Person{
        department : str;
    }
}

@msullivan msullivan self-assigned this Jun 28, 2023
msullivan added a commit that referenced this issue Jun 28, 2023
When passing objects to functions, there is an implicit dependence on
the `__type__` field (which may be used for function overloading).
This dependence isn't tracked, so in inheritance cases a computed
that depends on it may be processed before `__type__` is inherited.

Fix this by making sure to get `__type__` through proper channels.

Fixes #5661.

In addition to actually fixing it, I added a hack that will make
`__type__` always be processed first, to work around not easily being
able to repair the expr refs in existing databases. We can drop the hack
on our dev branch immediately, though.
(I tested this flow manually.)
msullivan added a commit that referenced this issue Jun 28, 2023
…5715)

When passing objects to functions, there is an implicit dependence on
the `__type__` field (which may be used for function overloading).
This dependence isn't tracked, so in inheritance cases a computed
that depends on it may be processed before `__type__` is inherited.

Fix this by making sure to get `__type__` through proper channels.

Fixes #5661.

In addition to actually fixing it, I added a hack that will make
`__type__` always be processed first, to work around not easily being
able to repair the expr refs in existing databases. We can drop the hack
on our dev branch immediately, though.
(I tested this flow manually.)
msullivan added a commit that referenced this issue Jul 6, 2023
…5715)

When passing objects to functions, there is an implicit dependence on
the `__type__` field (which may be used for function overloading).
This dependence isn't tracked, so in inheritance cases a computed
that depends on it may be processed before `__type__` is inherited.

Fix this by making sure to get `__type__` through proper channels.

Fixes #5661.

In addition to actually fixing it, I added a hack that will make
`__type__` always be processed first, to work around not easily being
able to repair the expr refs in existing databases. We can drop the hack
on our dev branch immediately, though.
(I tested this flow manually.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants