typedb/typedb 3.0.0-alpha-4

TypeDB 3.0.0-alpha-4

on GitHub

Install

Download from TypeDB Package Repository:

Distributions for 3.0.0-alpha-4

Pull the Docker image:

docker pull vaticle/typedb:3.0.0-alpha-4

New Features

• Include console in 3.0 distribution
  Includes console in 3.0 distribution. It can perform database management & run queries.

  Boot up server and console using the same binary, just like TypeDB 2.x:

  ./typedb server
  

  and

  ./typedb console
  

• Introduce reduce stages for pipelines
  Introduce reduce stages for pipelines to enable aggregates and group-aggregates.
  Aggregate operators available: count, sum max, min, mean, median, std

  Calculating mean duration of a site's visitors:

  match
    $page isa page, has url == "typedb.com";
    (page: $page) isa page-visit, has duration $duration;
  reduce $mean_visitor = mean($duration);
  
  // returns [ $mean_visitor ]
  

  Counting number of page visits grouped per website

  match 
    $page isa page;
    (page: $page, visitor: $visitor) isa page-visit;
  reduce $site_visitors = count($visitor) within $page; 
  
  // return [ $page, $site_visitors ] for each page
  

• Add support for ISO timezones; finalise datetime & duration support

Bugs Fixed

• Fix greedy planner: variables are produced immediately
• Fix QueryStreamTransmitter to not lose Continue signals and hang streaming operations
• Fix reboot bugs, update logging

Other Improvements

• Fix datetime-tz encode: send datetime as naive_utc instead of naive_local

• Fix datetimes: encode in seconds instead of millis

• Add query type to the query rows header. Implement connection/database bdd steps
  We update the server to server the updated protocol and return the type of the executed query as a part of the query row stream answer.
  We also fix the server's database manipulation code and implement additional bdd steps to pass the connection/database bdd tests.

• Fix within-transaction query concurrency

  We update the in-transaction query behaviour to result in a predictable and well-defined behaviour. In any applicable transaction, the following rules hold:

  1. Read queries are able to run concurrency and lazily, without limitation
  2. Write queries always execute eagerly, but answers are sent back lazily
  3. Schema queries and write queries interrupt all running read queries and finished write queries that are lazily sending answers

  As a user, we see the following - reads after writes or schema queries are just fine:

  let transaction = transaction(...);
  let writes_iter = transaction.query("insert $x isa person;").await.unwrap().into_rows();
  let reads_iter = transaction.query("match $x isa person;").await.unwrap().into_rows();
  
  // both are readable:
  writes_iter.next().await.unwrap();
  reads_iter.next().await.unwrap();
  

  In the other order, we will get an interrupt:

  let transaction = transaction(...);
  let reads_iter = transaction.query("match $x isa person;").await.unwrap().into_rows();
  let writes_iter = transaction.query("insert $x isa person;").await.unwrap().into_rows();
  
  // only writes are still available
  writes_iter.next().await.unwrap();
  assert!(reads_iter.next().await.is_err());