search

vaticle / typedb

TypeDB: the polymorphic database powered by types
https://typedb.com
Mozilla Public License 2.0
3.72k stars 337 forks source link

AttributeEntity #7027

Open maydanw opened 3 months ago

maydanw commented 3 months ago

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 commented 2 months ago

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.