FieldKind points to schema and collection by name but they are not always the same #2493
Assignees
Labels
area/collections
Related to the collections system
area/schema
Related to the schema system
bug
Something isn't working
Milestone
Comments
AndrewSisley
added
bug
AndrewSisley
changed the title
Closed
|
Note, I have a (early) WIP branch of name 2493-field-kind-schema-vs-col, breaking #2619 out of this task and working on that first. |
AndrewSisley
added a commit
that referenced
this issue
Sep 7, 2024
## Relevant issue(s) Resolves #2619 #2493 ## Description Reworks relation field kinds so that relations are not defined by names (which are mutable). This PR replaces the old `ObjectKind` and `ObjectArrayKind`s with `CollectionKind`, `SchemaKind` and `SelfKind`. `NamedKind` has also been added - it allows users to interact with the definitions using their names (like before), before the kind gets translated into one of the other new kinds before storage. Because Schemas must form a DAG (because of their CIDs (SchemaVersionID and Root), Schemas defined within the same action that form circular relations (e.g. User=>Dog=>User) have their CIDs grouped into a set with the same base id, plus an index relative to their lexographical order (name) within the set suffixed onto their CIDs. This change is not user visible, besides the `-[index]` suffix on their CIDs. Quite a lot had to change to facilitate this, and only a handful of things have been broken out to separate commits. Most of the work is in commit `Rework relation field kinds` - when reviewing that commit, I suggest starting with `tests/integration/collection_description/updates/replace/name_one_many_test.go` to see the original bug, followed by a quick scan of `client/schema_field_description.go`, then a look at `tests/integration/schema/self_ref_test.go` before properly reviewing the changes. The bulk of the self reference logic is in `internal/db/schema_id.go`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
And collection name is mutable, and thus a poor way of linking them.
We likely have a few references in the codebase that still assume they are the same and use the wrong means of getting a definition (relations).
Can only be done after #2451 as schemaField.Kind must point to the schema, and collectionField.Kind must point to the collection - at the moment they are the same property and thus cannot be detangled.
I suggest that collectionField.Kind references the linked collection by RootID, not by name, so that name mutations do not require a horrible cross-object update.
The text was updated successfully, but these errors were encountered: