Replies: 2 comments 4 replies
-
|
This would also allow displaying the graph model in Studio (#739) |
Beta Was this translation helpful? Give feedback.
-
|
I ilke the idea and the syntax, but how about:
|
Beta Was this translation helpful? Give feedback.
-
|
good point. How about inheritance ? Can we allow overriding ? For example: User --> HasAccount -> Account Do we implicitly allow SystemAccount to link to Account ? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, the inheritance will be used, so if you link the base type, all the subtypes will be allowed. @gramian what about ALTER PROPERTY Friend.@out OF TYPE Account;
CREATE PROPERTY User.data embedded OF TYPE UserData;
CREATE PROPERTY User.keywords list OF TYPE string;So we can use the same for limiting embedded properties, like EMBEDDED and LIST. WDYT? |
Beta Was this translation helpful? Give feedback.
-
|
I can see the appeal of this, but to me the typing of properties feel like constraints, so I thought wrt syntax of hence |
Beta Was this translation helpful? Give feedback.
-
|
Moving this discussion to an issue: #1174 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Recently asked on Discord, but discussed in many other topics and issues, we'd need a way to create constraints for edges so they can be attached only to specific vertex types.
The most natural way to achieve this is to mimic what OrientDB does: create constraints on
outandinproperties. While in OrientDBoutandinare real properties in the document, with ArcadeDB are managed in binary form (much faster), but then exposed to the users as respectively@outand@inmetadata.To provide constraints on edge we could simply allow the following syntax
alter property Friend.@out linkedtype Account;alter property Friend.@in linkedtype Account(in OrientDB wasLINKEDCLASS). This would meanFriendedge type can only connectAccountto anotherAccount.Beta Was this translation helpful? Give feedback.
All reactions