github vaticle/typedb 2.0.0-alpha-9
Grakn Core 2.0.0-alpha-9

latest releases: 2.28.0, 2.28.0-rc0, 2.27.0...
3 years ago

Install & Run: http://dev.docs.grakn.ai/docs/running-grakn/install-and-run

New Features

  • Include the Type of each Thing sent over RPC
    Previously, obtaining the Type of each Thing from a query (say, a Match query) meant adding a second network roundtrip to call getType on the Thing. For queries, this could be worked around by using isa! but this was cumbersome and in some cases, impossible (when building client libraries such as Workbase that needed to support any arbitrary query).
    Now, we include the Type of each Thing sent over RPC, meaning that getType can now be implemented on local Concepts in clients.

  • Asynchronous RPC Transaction Executor based on Event Loops
    Previously, GRPC executed all incoming requests on a "main" fixed-size thread pool, serially. When dealing with high throughput, this serial execution of the request will cause some "wait time" between the last request execution completed, and the next request received. This delay is enough to create noticeable thread inactivities, holding back the server from fully utilising the CPU cores of the machine.

Bugs Fixed

  • Prevent rare segfaults with storage read-write lock
    To prevent segfaults that can occur when a transaction has asynchronous work calling put() or get() on storage, after another thread has called close() on storage. To prevent this, we insert a read-write lock that needs to be obtained before each storage operation. Benchmark simulations show this isn't a major performance bottleneck, but we should still move towards more efficient implementations if possible (starting with investigating the use of Optimistic locking for low-contention locks)

  • Fix rule satisfiability validation
    We previously checked that a rule is coherent/satisfiability by checking each variable in the when and the then. However, we no longer set the satisfiability of a variable at all, instead setting only isCoherent at the conjunction. This PR updates Rule validation to reflect this change and removes isSatisfiable from Variable
    Fixes #6227

  • Fully remove rule indexes when undefining a rule
    As outlined in #6228, undefining a rule and committing appears to not completely clear the rule indices, causing subsequent null pointer exceptions. This PR actually deletes persisted rule indexes when undefining rules.

  • Rule materialisation lookups should use relation type
    We incorrectly fail to use the relation type when performing a traversal to lookup whether the rule conclusion is already satisfied with a given set of concepts. This PR includes the relation type correctly in the lookup, fixing several reasoning BDD scenarios (notably, recursion tests).

  • Remove offset and limit from reasoner
    It's incorrect to apply offset and limit inside reasoner, as we cannot sort natively. To do this properly, we keep offset and limit only at the top level iterator, and the caller is responsible for making sure that reasoner is not going to "over-compute" when a limit is present.

Code Refactors

  • Use isX, not 'instanceof' to check type encodings
    We refactored the codebase to ensure the isX methods of the subclasses of Concept are used consistently, not instanceof.

  • Type resolver marks non-schema queries as not coherent
    During query exection, we now throw an exception when any part of a query is not satisfiable (now known as not coherent), as detected by recursive type resolution. However, we only run type resolution on queries that may touch data, and set the non coherent flag on such queries.

  • Resolver track per-request state with non-generic data structures
    To clean up the resolution Resolver architecture, we need to get rid of the overly-generic data structure that was used by all resolvers to track responses per request. To allow resolvers to share some structure, we parametrise Compound resolvers by the type of response data structure they will use.

  • Only use Mapped answer state when resolvers change variables
    The Mapped answer state should only be used when mapping between variable spaces, ie. only when using a ConcludableResolver. More simple use cases that stay in the same variable space, possibly with a filter, should use Filtered.

Other Improvements

  • **Parallel configuration is available in all options **
    To enable setting parallel execution above solely the query level, we push the parallel option from Options.Query up to the parent class Options, making it available in all types of Options.

Please refer to full release notes of 2.0.0-alpha to see the changes in 2.0.0.

Don't miss a new typedb release

NewReleases is sending notifications on new releases.