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

AttributeEntity #7027

Open
maydanw opened this issue Apr 4, 2024 · 1 comment
Open

AttributeEntity #7027

maydanw opened this issue Apr 4, 2024 · 1 comment

Comments

@maydanw
Copy link

maydanw commented Apr 4, 2024

Problem to Solve

As in TypeDB 3.0 it will not be possible to have a relation to attributes (or attributes to attributes) it will make it much harder to have a change tracking, permission, or any other context to an attribute.

Current Workaround

Always work with Entities warping an attribute

Proposed Solution

Add an abstract AttributeEntity which is an entity that MUST have an attribute named value but can be extended as any other entity. This entity will be a synthetic sugar around the entity and it will be possible to define it with OWNS. Behind the scenes it will create a relation of type DESCRIBES with this entity. When querying it will be possible to use the HAS keyword which will behind the scenes retrieve the value attribute from the entity across the DESCRIBE relation and treat it as an attribute. Yet, if required it will be possible to traverse the relationship and then work with it as an entity (having relations and other attributes e.g., last_update_date, version, information_source_name).
By adding this synthetic sugar it will be possible to retain the option to have attributes as objects with independent context while keeping the simplicity of working with regular attributes for the majority of cases.

Additional Information

@brettforbes
Copy link

Absolutely!! Currently, the only method of doing version control between a UI context storage and local TypeDB, or between a local (team) TypeDB and a central (enterprise) TypeDB, is to export the relevant contents to JSON, and compare the two using DeepDiff . This generates an intermediate differences file. Finally, one has to transpile that into (match, insert, update, delete) TypeQL statements. We can do this, it just seems unnecessarily fragile.

It would be far more efficient if we could annotate attributes directly (i.e. append other information to them).

Further, in military, or access-controlled environments, one needs to track who read, wrote, edited, or deleted an attribute, and when!!! This would be very difficult to do currently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants