TypeDB 3.0 Roadmap #6764
Comments
|
Let's make sure each of them is documented properly in an issue, @flyingsilverfin |
|
Yes @haikalpribadi that's what the colons are for :D I have to get to that next |
|
Internal changes A TypeQL
RPC
Pattern & Resolvables
** Concepts **
Traversal & Reasoner
|
|
Thank you guys for working on this and sharing it with us. Optionals/fetch#6322 Vectors and ordered listsI see they've been discarded :S, but there is no simple workaround for this: VectorsWe don't need them as a particular attribute types, maybe a Storing something like this in typeDB is really hard, and mutate it (add items at particular positions) in a performant way is near to impossible Ordered listsThis also includes ordered lists with repeated values which are really hard to store in typeDB. |
|
The idea of banning attributes from playing roles is a disaster idea, forcing us back into the nightmare modelling world were everything must be an entity. Please god do not remove role-playing from attributes!!!!!! There is no benefit, and so much downside. I can show you plenty of examples where this feature is essential, that cannot be solved by structs!!!!! Why become just like the dumbo graphs and force us into false modelling ideas, where everything must be an entity, even if it is not a thing??? It is easy to derive a false premise when examining toy problems. This goes against Type Theory as propounded by Christoph!! How are you better than Neo4j if you make this move??? This is the single-most distressing conceptual idea I have ever seen. Terrible idea |
|
An example of why attributes that play roles are so powerful. this could not be done in any other database. Its a part of a schema where a language application links a dictionary meaning (sense) to all of its relatives. Just look at thow powerful typeDB is. So if you take away this ability, how will you solve this schema??? @flyingsilverfin Do we need to look for a new database that can handle this? |
|
What is the reason for removing the ability for multiple role owners of the same type. Once again, you break all of our code, but this time there is no alternative for a list of relations. Why do you keep breaking our code base. what possible benefit is there? Do you have an alternative, because every one of our 90 database objects uses this feature. This one is terrible because it breaks a lot of use cases, and it inhibits the use of list of relations. There seems to be no alternative for a list of relations, so once again there is breaking code with a terrible alternative, instead of one relation with a list of roles, i need multiple relations. Consider a simple scenario, where i have lists of references that get turned into relations, so match insert $incident isa incident, $stix-type "incident"; $incident-ext isa incident-ext, $extension-type "property-extension"; $occurence-ext0 (occurence:$incident, incident-core:$incident-ext) isa occurence-ext; $task-refs0 (incident:$incident-ext, the-task:$task00, the-task:$task10, the-task:$task20, the-task:$task30, the-task:$task40, the-task:$task50) isa task-refs; $event-refs0 (incident:$incident-ext, the-event:$event00) isa event-refs; $impact-refs0 (incident:$incident-ext, the-impact:$impact00, the-impact:$impact10) isa impact-refs; $other-obj-refs0 (object:$incident-ext, referred:$email-addr00, referred:$user-account10, referred:$email-addr20, referred:$email-message30, referred:$url40, referred:$stix-core-relationship50, referred:$observed-data60, referred:$indicator70, referred:$sighting80, referred:$identity90, referred:$anecdote100, referred:$observed-data110, referred:$sighting120, referred:$user-account130, referred:$user-account140, referred:$user-account150, referred:$email-addr160, referred:$user-account170, referred:$email-addr180, referred:$sighting190, referred:$stix-core-relationship200, referred:$stix-core-relationship210, referred:$stix-core-relationship220, referred:$observed-data230, referred:$identity240, referred:$ipv4-addr250, referred:$domain-name260, referred:$observed-data270, referred:$indicator280, referred:$sighting290, referred:$location300, referred:$identity310, referred:$stix-core-relationship320, referred:$sighting330, referred:$software340, referred:$file350, referred:$process360, referred:$stix-core-relationship370, referred:$stix-core-relationship380, referred:$stix-core-relationship390, referred:$observed-data400, referred:$sighting410) isa other-obj-refs; |
|
I think the proposal is only to remove repeated roles & players
role1: $player1, role1: $player1
While this would keep working:
role2: $player1, role2: $player2
So it's not about removing the cardinality MANY of roles, but removing the
possibility of a player to play the same role multiple times.
So basically, no repetition. Which I agree is not the most common use case
out there. But it does happen.
Btw a workaround for this in the new format would be to create an
intermediary entity "event" for instance so instead of A<>B & A<>B we would
have to do A<>EV1<>B & A<>EV2<>B
|
|
Thanks for the cogent response. It turns out that i was just being paranoid then, my bad. I have just been getting concerned about the amount of capabilities we built our stack on that may be being nerfed in v3.0. I am glad this cardinality one is a non-issue and i really appreciate your response putting me at ease. |
|
Hi All, After speaking to Haikal, there are good reasons to move from the Concept API to Fetch, particularly speed. At present it takes between 2-5 secs to retrieve an object from TypeDB and transpile it to valid Stix JSON. This is mainly due to all of the network roundtrips that have to be done, so clearly one fetch query will be more effective. The advantage of our current system is it is shape-based, so I can handle all JSON objects using the same ORM, the disadvantage is speed. The new approach does mean a lot more code, since we have to build quite long Fetch statements for each individual object (e.g. 16-44) lines for each of our 85 objects, and then build the transpile code (from returned Fetch JSON to Stix JSON). This figure assumes a single main object, 4 lines, and then 3-11 optional sub objects with relations, with 4 lines each, if we use the class hierarchy. But the benefit will be far greater speed, totally agreed. We probably wont be able to make this move for some months, due to resourcing, but we agree it will be worth it. At the same time we can update our 2.500 lines of schema code to v3. This will place us in good position to add on another 50-80 cybersecurity objects (e.g. SBOM's, Vulnerabilities, Risk etc.) Onwards and upwards for TypeDB and our cybersecurity application!! |
Problem to Solve
We collect the agreed list of changes and requirements that will be in the first version of TypeDB 3.0.
Changes
API
Driver
TypeQL
Value restriction:
Require further discussion:
Relation implementation
Changes proposed and rejected:
The text was updated successfully, but these errors were encountered: