You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Within the models we have a specialized type for schema item ID's which are treated as validated strings. It would be really useful to create a new item type that treats ID's as foreign keys. We could expand the serialization so that when we return a model with a foreign key, it actually looks up and includes that model. Likewise, we can also have items removed when foreign keys are required and subsequently deleted. It might be beneficial to separate foreign key types. We could specify different relationships that would do different things based on the request type.
I think there are two basic types of foreign keys.
required-key
optional-key
Example use-cases
required-key
Say you have a project model. Each project can create several asset models, each of which needs the project ID as a reference (currently saved as an ID). If instead we treated the project ID as a foreign key (of type required-key), we could expand the functionality so that if the project is deleted, all database rows that have a required-key matching the project must be deleted as well.
optional-key
Say you have a project model and each has an optional-key 'active-image' that points to an image resource. If the image resource is removed, the project key for active-image must be nullified. Because the active-image is an optional-key, if the project resource is deleted, the image resource is left in the database.
Serialization
Each foreign key should optionally be retrieved when fetching serialized models. There should be a parameter check for 'include foreign keys', which if true, will append the key model to the serialized object.
Proposed methodology
Each model instance would keep two separate arrays. One for required dependencies and one for optional ones. When the instance is deleted, the delete function initiates a chain of events removing / nullifying each of the items in the respective dependency arrays.
The schema item for foreign keys will specify which collection and identifier the dependency will be added to (i.e. its up to the child item to add the foreign key to the target). Each of the dependencies added to the target would likely have a collection and Id property to identify the resources to target upon deletion.
The text was updated successfully, but these errors were encountered:
Within the models we have a specialized type for schema item ID's which are treated as validated strings. It would be really useful to create a new item type that treats ID's as foreign keys. We could expand the serialization so that when we return a model with a foreign key, it actually looks up and includes that model. Likewise, we can also have items removed when foreign keys are required and subsequently deleted. It might be beneficial to separate foreign key types. We could specify different relationships that would do different things based on the request type.
I think there are two basic types of foreign keys.
Example use-cases
required-key
optional-key
Serialization
Each foreign key should optionally be retrieved when fetching serialized models. There should be a parameter check for 'include foreign keys', which if true, will append the key model to the serialized object.
Proposed methodology
Each model instance would keep two separate arrays. One for required dependencies and one for optional ones. When the instance is deleted, the delete function initiates a chain of events removing / nullifying each of the items in the respective dependency arrays.
The schema item for foreign keys will specify which collection and identifier the dependency will be added to (i.e. its up to the child item to add the foreign key to the target). Each of the dependencies added to the target would likely have a collection and Id property to identify the resources to target upon deletion.
The text was updated successfully, but these errors were encountered: