TypeDB 2.x to TypeDB 3.x: what’s changed
This page outlines the key updates of TypeDB 3.x compared to 2.x you should be aware of while transitioning between these versions.
This section highlights changes from TypeDB 2.x, not all new features in 3.x. Explore the Manual, TypeQL Documentation, and release notes for the full picture. Stay tuned for upcoming blogs showcasing new features! |
Click on a feature below for detailed documentation and examples.
TypeDB and TypeQL
-
Sessions Removed: Connections to TypeDB now only require opening a
schema
,write
, orread
transaction. -
Integer Value Type Renamed:
long
is nowinteger
. -
Kinds Introduced: no more predefined root types and their subtyping through
person sub entity
,friendship sub relation
, orname sub attribute
. Each new type should be declared with an explicit kind:entity person
,relation friendship
, andattribute name
. Check out Schema modeling for more. -
Expanded User Management: Authorization and user management are now included in all TypeDB editions. Default credentials, if applicable, can be found in the Connection Manual.
-
Updated Query Syntax:
-
undefine
anddelete
now explicitly "point" to their removed targets, reducing ambiguity. -
fetch
syntax aligns with JSON output formatting. -
match
produces visible row-like results itself (similarly toinsert
, etc): no moreget
s! -
All
$vars
start with$
: no more?
for value variables! However, it is still easy to differentiate their declaration with the newlet
keyword. Check out some read queries examples here.
-
-
Annotations and Statements Consolidated:
abstract
andregex
are now grouped under @annotations. -
Smoother trait specialization:
-
It is possible to redefine already inherited
owns
andplays
on subtypes, adding more annotations to them. -
As before, use the
as
keyword to specialize arelates
.
-
-
Default Cardinalities:
-
Default cardinalities are applied to
owns
,relates
, andplays
if not explicitly defined. -
Default
plays
cardinality:@card(0..)
(unlimited). -
Default
owns
andrelates
cardinality:@card(0..1)
(up to one instance). Explicitly define cardinalities for traits expecting multiple instances to avoid data corruption and optimize database performance.
-
-
Rules and Inference Replaced: Rules are now replaced by functions, requiring explicit functions execution instead of inference, but offering more abstraction and flexibility.
TypeDB Drivers
API Simplification for smoother UX and better maintenance. Visit the Drivers manual to access their full documentation.
-
Now, all schema and data fetching and modifications are performed through a single
transaction.query("your query")
interface. -
No more
query().insert()
andquery().define()
. -
No more
concept.delete()
orconcept.getHas()
. -
Concept structure is preserved (the only difference:
Thing
is renamed toInstance
), casts are available, and it is possible to retrieve something simple as a type’s label or an attribute’s value, that are sent with the type itself. -
In OOP languages (like Java and Python), concepts have
try
versions of their methods, available for any concept and returning optional results. Using casting, the concrete methods returning results directly become available, as in 2.x.
Temporarily missing features
This section contains the list of features that were introduced in 2.x, but are still under development in 3.x. Coming soon! Take into account that some of your processes can be blocked if you previously relied on these features.
TypeDB and TypeQL
-
Instantiation restriction for inherited
owns
andplays
(used toas
). An enhanced approach is in development (NOTE: you don’t need theas
keyword to specialize an ownership of an inherited super attribute type with an ownership of its subtype, but you cannot "hide" the original definition from inheritance). -
Scaling support for Cloud and Enterprise editions.
TypeDB Drivers
-
Node.js, C, C++, and C# drivers are not yet available. Consider using one of the available languages or the HTTP Endpoint.
Having troubles?
For troubleshooting tips and guidance, refer to the Troubleshooting Manual.