Migration assistant misidentifies link property types of computed properties in schema with multiple levels of inheritance

[corbinday]

The migration tool struggles with some aspects of multi-level inheritance hierarchies.

It appears that when a computed property is of a subclass type with a parent that overloads a link property, the migration tool thinks that the link properties are of the base class type and it thinks there's a missing conversion expression.

Here's an example schema that I cannot create a migration for because of the computed height properties in the User type:

module default {

  type User {
    height := .<user[is HeightReply]; # 👈 Problem is here
    alternateHeight := (select HeightReply filter .user.id = __source__.id); # 👈 And here
  }
  
  abstract type Question;

  type HealthQuestion extending Question;

  abstract type Reply {
    required user: User;
    required single question: Question;
  }

  abstract type UserInputReply extending Reply {
    overloaded link question: HealthQuestion;
  }

  type HeightReply extending UserInputReply;
}

It fails with this message:

SchemaError: link 'question' of object type 'default::HeightReply' cannot be cast automatically from object type 'default::Question' to object type 'default::HealthQuestion'
  Hint: You might need to specify a conversion expression in a USING clause

The migration tool doesn't complain if you move overloaded link question: HealthQuestion from UserInputReply to HeightReply. It also doesn't complain if you remove the computed properties from the User type.

---

• EdgeDB Version: 4.5+641a8f3
• EdgeDB CLI Version: 4.0.2+500be791
• OS Version: macOS 14

Steps to Reproduce:

1. Initialize project with the given schema.
2. Attempt to make initial migration.

[corbinday]

Based on #6766 seems like it's actually an issue with the order of appearance in the schema of overloading types or anything that references them.

[come2thecabaret]

Encountering this same issue involving overloading a link from an abstract parent type, and getting this same error depending on the order in which types are defined. It makes splitting our large schema into multiple files troublesome. In general it will be difficult to precisely manage the order in which types are defined given the complexity of our schema.