vmware/differential-datalog v0.38.0

DDlog v0.38.0

on GitHub

[0.38.0] - Mar 11, 2021

API changes

There are some breaking API changes in this release:

• Rust API:

  • Factored the Rust API into several traits declared in the
    differential_datalog crate:
    • trait DDlogDynamic - works with data represented as records.
    • trait DDlog - extends DDlogDynamic to work with strongly typed
      values wrapped in DDValue.
    • trait DDlogProfiling - profiling API.
    • trait DDlogDump - dump tables and indexes.
    • DDlogInventory - convert between relation/index names and numeric ids.
  • Renamed apply_valupdates -> apply_updates,
    apply_updates -> apply_updates_dynamic.
  • Changed method signatures to eliminate any generics. This way we will
    be able to implement dynamic dispatch for the DDlog API (i.e., pass
    references to a DDlog program as &dyn DDlogXXX) in the future.

• C, Java, Go API. ddlog_get_table_id, ddlog_get_index_id methods now
  require a DDlog instance, e.g., old signature:

  extern table_id ddlog_get_table_id(const char* tname);
  

  new signature:

  extern table_id ddlog_get_table_id(ddlog_prog hprog, const char* tname);
  

Libraries

• Functional HashSets, aka immutable hashsets (lib/hashset.dl). At the API
  level functional hashsets behave just like regular hashsets; however their
  internal implementation supports cloning a hashset in time O(1) by sharing the
  entire internal state between the clone and the parent. Modifying the clone
  updates only the affected state in a copy-on-write fashion, with the
  rest of the state still shared with the parent.

  Example use case: computing the set of all unique id's that appear in a
  stream. At every iteration, we add all newly observed ids to the set of
  id's computed so far. This would normally amount to cloning and modifying a
  potentially large set in time O(n), where n is the size of the set. With
  functional sets, the cost if O(1).

  Functional data types are generally a great match for working with immutable
  collections, e.g., collections stored in DDlog relations. We therefore plan
  to introduce more functional data types in the future, possibly even
  replacing the standard collections (Set, Map, Vec) with functional
  versions.

ovsdb2ddlog compiler

• Added --intern-table flag to the compiler to declare input tables coming from
  OVSDB as Intern<...>. This is useful for tables whose records are copied
  around as a whole and can therefore benefit from interning performance- and
  memory-wise. In the past we had to create a separate table and copy records
  from the original input table to it while wrapping them in Intern<>. With
  this change, we avoid the extra copy and intern records as we ingest them
  for selected tables.