3.0 Define and Redefine

[farost]

Usage and product changes

We add define and the first version of redefine queries to TypeDB 3.0, excluding functions and aliases.

Implementation

Definition (and redefinition) order of types (it can be changed) :

• types
• types' alias (can be moved up if anything depends on it later, like "set type alias" + "alias set annotation ..."
• types' value types (doesn't depend on anything)
• types' annotations (can potentially depend on value types)
• types' subs (expects all types to be already declared, can depend on annotations: @abstract)
• relates + annotations (expects all types. Annotation is a capability of a capability, doesn't depend on anything above)
• relates overrides (expects all relates to be previously declared)
• owns + annotations (same as for relates + annotations)
• owns overrides (same as for relates overrides)
• plays + annotations (expects all relates to be declared + same as for relates + annotations)
• plays overrides (same as for relates overrides)

Redefinition follows the same logic now, but:

• overrides update call doesn't wait for all the other capabilities' updates and is called right after annotations update;
• allows only one update per query (for simplicity: redefine requires much more work on its planner to execute queries in a smart way).

define and redefine queries use two common files: definition_resolution and definition_status. definition_resolution contains common functions to search for / wrap into errors type axioms, constraints, etc. It is directly used when we only need to search for a specific something and only wish for success. definition_status is used to get the status of something we search for: DoesNotExist / ExistsSame / ExistsDifferent. It is a simple and convenient (for both creating and refactoring) way to describe how to act in different queries like define/redefine/undefine based on the status of the definition. Of course, it uses definition_resolution as its basis.

Ordering is removed from set_owns in Concept API. set operations are idempotent, and providing ordering to this operation is risky, you always need to read ordering from storage when you call for this operation. Moreover, we need to worry about ordering's change, cover it with additional tests while not necessarily using it, etc. Better solution: set_owns + set_owns_ordering. Ordering is set to unordered by default, which should be the most common case, and it shouldn't be a really excessive operation.

Ordering is still a part of create_relates as:

• it is a create, a non-idempotent operation. We don't expect to call it twice for the same relates;
• it is generally a complex creation operation of both relates and role types, and it's a bit more reasonable to have it more configurable.
• we already (not for long) have another parameter Cardinality in this api call, so removing Ordering is only a half-way cleaning. However, I'd only support the decision to remove Ordering from creates in the future, too. It can be done in a separate PR.

[typedb-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• [x] This change is trivial and does not require a code or architecture review.

Code

• [ ] Packages, classes, and methods have a single domain of responsibility.
• [ ] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [ ] The code is canonical and the minimum required to achieve the goal.
• [ ] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [ ] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [ ] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [ ] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [ ] Any required build and release automations are updated and/or implemented.
• [ ] Any new components follows a consistent style with respect to the pre-existing codebase.
• [ ] The architecture intuitively reflects the application domain, and is easy to understand.
• [ ] The architecture has a well-defined hierarchy of encapsulated components.
• [ ] The architecture is extensible and scalable.

[farost]

Build will be green once I update refs from other repos.