0.19.2 - Performance improvements for Get(explore)

Docker image/tag: semitechnologies/weaviate:0.19.2

Performance Increases

• Faster exploration on GraphQL Get() queries (#943)
  If the explore: { ... } argument is set, the results will now be served entirely through the esvector backend. This leads to very significant performance improvements with result sets > 20 items.
  Note that
  • If an explore argument is set, cross-refs cannot be resolved. This is the limitation as before and will be resolved with the upcoming 0.20.x releases
  • If no explore argument is set, the query is answered by the "traditional" connector backend (usually Janusgraph). This still supports cross-refs.

0.19.1 - Fix critical index inefficiency in Janusgraph Setup

Docker image/tag: semitechnologies/weaviate:0.19.1

Fixes

• Critical Indexing inefficiency in Janusgraph Setup (#939)
  This releases fixes a critical issue where Janusgraph would do a (very inefficient) whole graph traversal, rather than efficiently use the attached index - often leading to request timeouts.

Notes

• Because of the criticality of this fix, it is fixed in releases 0.16.x, 0.17.x, 0.18.x and 0.19.x while usually only the latest release is supported.

0.19.0 - Breaking Changes in all APIs

Docker image/tag: semitechnologies/weaviate:0.19.0

This releases bundles a lot of breaking changes, with the intent to able to keep a stable API after those (required) changes.

Breaking Changes

• API base path now /v1
  Previously the API base path was /weaviate/v1. This releases changes this to the more concise /v1.

• GET /meta no longer returns schema
  Information about the schema can still be retrieved using GET /schema

• GraphQL Root-Level Field GetMeta renamed to Meta
  To be consistent with other GraphQL fields, such as Aggregate

• Specify a direct reference with beacon instead of $cref
  When adding a cross-reference the field $cref was renamed to beacon to be more consistent with the overall naming. A Beacon represent an exact reference to a single class object identified by its UUID.

• Cross-References always represented as an array
  Prior to this, Cross-References were reflected as a single object when the cardinality was set to atMostOne, but represented as an array, when the cardinality was set to many. Now references are represented as arrays. The following APIs are affected by this:

  • POST /things and POST /actions only when the class to be added contains a reference. For example, {"class": "City", "schema":{"inCountry": [{"beacon": "..."}]}}
    Note that the value for"inCountry"is now an array, regardless of the cardinality of inCountry. The same applies for updating a class using PUT /things/<id> and PUT /actions/<id>
  • PATCH /things and PATCH /actions if patch semantics are used to add a cross-ref. To add the first reference using PATCH, you can use the following payload to add the first reference (in case of cardinality atMostOne, this is the only one which can be added):

  [
    {
        "op": "add",
        "path": "/schema/inCity",
        "value": [
          {
            "beacon": "weaviate://..."
          }
       ]
    }
  ]

  The following APIs are not affected by this change:

  • POST /things/<id>/references/<refPropName> and POST /actions/<id>/references/<refPropName>, they can only be used with cardinality many where no changes have been applied
  • PUT /things/<id>/references/<refPropName> and PUT /actions/<id>/references/<refPropName>, they can only be used with cardinality many where no changes have been applied
  • /schema/* The above changes only affect adding or updating class objects (i.e. data), but have no implications on the schema related endpoints.
  • No clean upgrade path from 0.18.x
    Fields in the database were renamed between 0.18.x and 0.19.x. It is therefore preferable not to upgrade an instance from 0.18.x, but instead to provision a clean one at 0.19.x and re-import data.

Non-breaking Changes

• GET /meta returns additional information
  Now included is information about the running version, the connected contextionary version and the number of words present in the contextionary.

Currently unsupported APIs

This release already adds some future functionality that is not yet implemented. Using those APIs will either lead to explicit errors or (in the case of an additional argument) to unaltered behavior. The implemenation for those features will follow in the coming weeks and months.

• Group option added to GraphQL Get -> Things/Actions -> ClassName Field
  Specifying group: {type: "closest|merge", force: 0.9} is possible, however has no effect at the moment. An implementation will follow at a later point
• Add Concept Cross-References as opposed to Direct Cross-References
  In addition to direct refrences using [{ "beacon": "..." }] it will also be possible to add concept (or "fuzzy") references by specifying a matching "class" and desired "schema" in the future. This functionality is not present yet and trying to add a concept reference will lead to an error in 0.19.0. Please refer to the docs for more information about this upcoming feature.
• Add ...on Beacon to Cross-Refs in GraphQL Get API
  In addition to resolving an exact reference by specifying the class name, e.g. InCity { ... on City { name } } it will also be possible to retrieve only a beacon, i.e. a reference URI to the desired class object using ...on Beacon, e.g. InCity { ... on Beacon { beacon } } in the future. Trying to use this feature in 0.19.0 will error.

0.18.2 - Fix critical index inefficiency in Janusgraph Setup

Docker image/tag: semitechnologies/weaviate:0.18.2

Fixes

• Critical Indexing inefficiency in Janusgraph Setup (#939)
  This releases fixes a critical issue where Janusgraph would do a (very inefficient) whole graph traversal, rather than efficiently use the attached index - often leading to request timeouts.

Notes

• Because of the criticality of this fix, it is fixed in releases 0.16.x, 0.17.x, 0.18.x and 0.19.x while usually only the latest release is supported.

0.17.2 - Fix critical index inefficiency in Janusgraph Setup

Docker image/tag: semitechnologies/weaviate:0.17.2

Fixes

• Critical Indexing inefficiency in Janusgraph Setup (#939)
  This releases fixes a critical issue where Janusgraph would do a (very inefficient) whole graph traversal, rather than efficiently use the attached index - often leading to request timeouts.

Notes

• Because of the criticality of this fix, it is fixed in releases 0.16.x, 0.17.x, 0.18.x and 0.19.x while usually only the latest release is supported.

0.16.3 - Fix critical index inefficiency in Janusgraph Setup

Docker image/tag: semitechnologies/weaviate:0.16.3

Fixes

• Critical Indexing inefficiency in Janusgraph Setup (#939)
  This releases fixes a critical issue where Janusgraph would do a (very inefficient) whole graph traversal, rather than efficiently use the attached index - often leading to request timeouts.

Notes

• Because of the criticality of this fix, it is fixed in releases 0.16.x, 0.17.x, 0.18.x and 0.19.x while usually only the latest release is supported.

0.18.1 - Combine Vector and Structured Search

Docker image/tag: semitechnologies/weaviate:0.18.1

New Features

• Combined Vector and Structured Search (#911)
  Previously in 0.17.0 Vector Search was added as a new feature set. As opposed to the initial realease it is now possible to combine the explore argument with a where argument in a Get retrieval. This allows for using the vector-based exploration queries to rank the results, yet filter them by exact strings, keywords or even geo-spatial data.

  For an example query see the following:

  {
    Get {
      Things {
        Company(
          explore: {concepts: ["phone"]}, 
          limit: 20, 
          where: {
            valueString: "Information Technology", 
            operator: Equal, 
            path: ["sector"]
          }) {
          name
          sector
          subIndustry
        }
      }
    }
  }

  This query explores the concept "phone" through all Companies, however it only includes results where the sector fields matches "Information Technology" precisely.

0.18.0 - GQL Breaking Changes

Docker image/tag: semitechnologies/weaviate:0.18.0

Breaking Changes

• GraphQL API Changes (#925)
  • Local and Network fields are removed in GraphQL API
  • { Local { Get {...} } } moves to { Get {...} }, likewise for Explore, Aggregate, GetMeta
  • Fetch API is entirely removed (functionality replaced through Explore
  • Network GraphQL API is entirely removed, network searches will only be possible through Explore(network: true) in the future

0.17.1 - Upgrade esvector to 7.1.0

Docker image/tag: semitechnologies/weaviate:0.17.1

Upgrades

• Upgrade esvector to 7.1.0 (#923)

Compatible Helm chart

• For Kubernetes deployments use the official helm chart at v6.0.0

0.17.0 - Vector Search

Docker image/tag: semitechnologies/weaviate:0.17.0

New features

• Vector indexing at import time
  When a concept is imported through a non-batch fashion, a vector-representation is created and stored in weaviate's vector db.
• GQL{ Local { Explore }} (#888, #904)
  A new GQL Field was added which allows to search for concepts rather than keywords. The request is served through weaviate's vector searching backends. (Docs not up to date yet, coming soon!)
• New GQL argument explore() in { Local { Get }} (#906)
  The existing { Local { Get } } API was extended with a new explore() parameter, which allows for a concept (vector-based) search in addition to the classical where() structured search

Known limitations

• Roadmap
  See #907 for the road map of related features

Breaking Changes

• New esvector backend
  If the new vector-based concept search should be used, a new esvector backend is required. See the docker-compose/runtime/docker-compose.yml file for an example
• Reimport required for Vector Creation
  While the changes themselves are not breaking, vectors are currently only created at import time. There is no reindex feature yet. So we strongly recommend to setup an empty weaviate installation and reimporting all concepts when moving to 0.17.x