Skip to content

Releases: block/elasticgraph

v1.0.2

19 Sep 17:33
@github-actions github-actions
v1.0.2
1a92ebd

Choose a tag to compare

View all tags
v1.0.2 Latest
Latest

New Features

Documentation Changes

Internal Changes

Dependency Changes

  • build(deps-dev): bump tailwindcss from 4.1.11 to 4.1.12 in /config/site in the npm group by @dependabot[bot] in #801
  • build(deps): update mcp[cli] requirement from ~=1.12.3 to ~=1.13.0 in /ai_tools/elasticgraph-mcp-server in the pip group by @dependabot[bot] in #802
  • Upgrade codespell to 2.4.1 on CI. by @myronmarston in #806
  • build(deps): bump the most-gems group with 12 updates by @dependabot[bot] in #822
  • build(deps): bump aws-sdk-sqs from 1.100.0 to 1.101.0 in the most-gems group by @dependabot[bot] in #823
  • build(deps): bump the most-gems group with 7 updates by @dependabot[bot] in #829
  • build(deps): bump the most-gems group with 12 updates by @dependabot[bot] in #830
  • build(deps): bump rack from 3.2.0 to 3.2.1 by @dependabot[bot] in #837
  • build(deps): bump elasticsearch from 9.1.1 to 9.1.2 by @dependabot[bot] in #836
  • build(deps-dev): bump rbs from 3.9.4 to 3.9.5 by @dependabot[bot] in #834
  • build(deps): bump the most-gems group with 11 updates by @dependabot[bot] in #835
  • build(deps): update pytest-cov requirement from ~=6.2.1 to ~=6.3.0 in /ai_tools/elasticgraph-mcp-server in the pip group by @dependabot[bot] in #833
  • build(deps-dev): bump tailwindcss from 4.1.12 to 4.1.13 in /config/site in the npm group by @dependabot[bot] in #832
  • build(deps): bump bigdecimal from 3.2.2 to 3.2.3 in /config/release in the release-gems group by @dependabot[bot] in #831
  • build(deps): bump the most-gems group across 1 directory with 10 updates by @dependabot[bot] in #838
  • Update gem artifacts. by @myronmarston in #839
  • Lock graphql gem to 2.5.11 to resolve elasticgraph-apollo test failure introduced in 2.5.12 by @bsorbo in #842
  • build(deps): bump the release-gems group in /config/release with 2 updates by @dependabot[bot] in #846
  • build(deps): bump the pip group in /ai_tools/elasticgraph-mcp-server with 4 updates by @dependabot[bot] in #847
  • build(deps): bump the most-gems group with 10 updates by @dependabot[bot] in #843
  • build(deps-dev): bump standard from 1.50.0 to 1.51.1 by @dependabot[bot] in #844

New Contributors

Full Changelog: v1.0.1...v1.0.2

Contributors

myronmarston, bsorbo, and 2 other contributors
Assets 2
Loading

v1.0.1

18 Aug 22:32
@github-actions github-actions
v1.0.1
6d7a73a

Choose a tag to compare

View all tags
v1.0.1

ElasticGraph v1.0.1 has been released! This release includes an improved configuration system and a bug fixes.

New Features

New JSON Schemas for Configuration

We've added JSON schema validation to the configuration system. This provides improved defaulting and validation of setting YAML files and is the basis for several new documentation resources:

Upgrade notes

The elasticgraph-json_schema gem has been merged into the elasticgraph-support gem. If you've been listing elasticgraph-json_schema in your Gemfile, you'll need to remove it.

What's Changed

New Features

Bug Fixes

  • fix: Resolved an issue for numeric derived fields that contained values both within Integer and Long ranges by @ayousufi in #795

Other Improvements

New Contributors

Full Changelog: v1.0.0...v1.0.1

Contributors

myronmarston, ayousufi, and 2 other contributors
Loading

v1.0.0

04 Aug 22:59
@github-actions github-actions
v1.0.0
129aee9

Choose a tag to compare

View all tags
v1.0.0

ElasticGraph v1.0.0 has been released! This marks a significant milestone in the maturity of ElasticGraph.

This release includes a number of new features and the removal of several long-deprecated features.

New Features

Substring Filtering

ElasticGraph 1.0.0 offers a couple new filtering predicates for string fields.

The contains predicate provides substring filtering:

query AverageSongLengthForYouOrEye {
  artistAggregations {
    nodes {
      subAggregations {
        albums {
          nodes {
            subAggregations {
              tracks(filter: {
                name: {
                  contains: {
                    anySubstringOf: ["you", "eye"]
                    ignoreCase: true
                  }
                }
              }) {
                nodes {
                  groupedBy {
                    name
                  }

                  aggregatedValues {
                    lengthInSeconds {
                      approximateAvg
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

The startsWith predicate provides prefix filtering:

query ArtistsPrefixedWithThe {
  artists(filter: {
    name: {
      startsWith: {
        anyPrefixOf: ["The "]
      }
    }
  }) {
    edges {
      node {
        name
      }
    }
  }
}

Search Highlighting

When searching through textual data it can be very useful to know where matches occurred in the returned documents. For example, to power a "global search" box that lets users search across all string/text fields, you could use a query like this:

query GlobalSearch(
  $query: String = "Rock" # an example search term; replace with whatever you want
) {
  artists(filter: {
    anyOf: [
      {albums: {anySatisfy: {name: {contains: {anySubstringOf: [$query]}}}}}
      {albums: {anySatisfy: {tracks: {anySatisfy: {name: {contains: {anySubstringOf: [$query]}}}}}}}
      {bio: {homeCountry: {equalToAnyOf: [$query]}}}
      {bio: {description: {matchesQuery: {query: $query}}}}
      {name: {contains: {anySubstringOf: [$query]}}}
      {tours: {anySatisfy: {name: {contains: {anySubstringOf: [$query]}}}}}
    ]
  }) {
    edges {
      node {
        name
      }

      highlights {
        albums {
          name
          tracks {
            name
          }
        }

        bio {
          homeCountry
          description
        }

        name

        tours {
          name
        }
      }
    }
  }
}

ElasticGraph also offers allHighlights as an alternative to highlights which allows the query to be simplified a bit:

query GlobalSearchV2(
  $query: String = "Rock" # an example search term; replace with whatever you want
) {
  artists(filter: {
    anyOf: [
      {albums: {anySatisfy: {name: {contains: {anySubstringOf: [$query]}}}}}
      {albums: {anySatisfy: {tracks: {anySatisfy: {name: {contains: {anySubstringOf: [$query]}}}}}}}
      {bio: {homeCountry: {equalToAnyOf: [$query]}}}
      {bio: {description: {matchesQuery: {query: $query}}}}
      {name: {contains: {anySubstringOf: [$query]}}}
      {tours: {anySatisfy: {name: {contains: {anySubstringOf: [$query]}}}}}
    ]
  }) {
    edges {
      node {
        name
      }

      allHighlights {
        path
        snippets
      }
    }
  }
}

Rather than providing the nested structure with named fields provided by highlights, this provides the highlights as a flat
list of SearchHighlight objects, each of which has a path indicating the matching field.

Bundled GraphiQL UI

Before ElasticGraph 1.0.0, ElasticGraph provided a version of GraphiQL that dependened on a CDN (https://esm.sh/) to work. This generally worked fine, but it relied on an active internet connection to work, and ElasticGraph's GraphiQL UI would stop working if the CDN had some downtime.

ElasticGraph 1.0.0 now bundles all GraphiQL assets in a new elasticgraph-graphiql gem. As part of this, we've upgraded GraphiQL from 4.0.0 to 5.2.0.

Support for Elasticsearch 9.1 and OpenSearch 3.0/3.1

ElasticGraph 1.0.0 supports these recently released versions of Elasticsearch and OpenSearch.

Upgrade notes

This release drops support for some legacy features which provided backwards compatibility for old ElasticGraph projects. The upgrade should be quite easy for most existing projects. Here's a detailed checklist.

Verify Ruby Compatibility

This release drops support for Ruby 3.2 and 3.3, requiring Ruby 3.4, which has been supported since ElasticGraph v0.19.1.0. Confirm you're using Ruby 3.4.x on CI and in production before proceeding.

Verify OpenSearch Compatibility

This release drops support for OpenSearch 2.7 to 2.18, requiring 2.19 or greater. If you're using OpenSearch in production, confirm it's version is 2.19 or greater before proceeding.

Remove nested_relationship_resolver_mode from GraphQL configuration

This option was added in ElasticGraph 0.19.2.0 when we were first rolling out the nested relationship performance optimization, so that existing projects could carefully roll that out if desired. Verify that nested_relationship_resolver_mode has been removed from your project's settings YAML files.

Verify Index Compatibility

ElasticGraph v0.9 featured a large change to how indexing worked. As part of that change, ElasticGraph began using a Painless update script for all indexing. All ElasticGraph projects bootstrapped since that time automatically use the new Painless script, but projects that started before that time may still use the old approach. Unfortunately, an index that has been written to using the old approach cannot safely be written to using the Painless update script. A backwards-compatibility mode has been kept around in ElasticGraph since that time, but ElasticGraph 1.0.0 removes it.

If your project predates ElasticGraph v0.9, you'll need to confirm your indices are ready for ElasticGraph 1.0.0 before proceeding:

  • Verify that use_updates_for_indexing: false is not configured in any of your settings YAML files.
    • If use_updates_for_indexing: true is configured, you'll need to remove that configuration. Indexing always uses updates, and no configuration is supported to control it.
  • Verify that all indexed documents have a __versions field. To check, use the dev tools console in Elasticsearch Kibana or OpenSearch dashboards and run one of the following queries:

For OpenSearch:

POST /*,-excluded_index1,-excluded_index2/_search
{
  "derived": {
    "has_versions": {
      "type": "boolean",
      "script": {
        "source": """
          def s = params._source;
          if (s == null) { emit(false); }
          else { emit(s.containsKey("__versions")); }
        """
      }
    }
  },
  "query": {
    "term": { "has_versions": false }
  },
  "_source": true,
  "size": 10
}

For Elasticsearch:

POST /*,-excluded_index1,-excluded_index2/_search
{
  "runtime_mappings": {
    "has_versions": {
      "type": "boolean",
      "script": {
        "source": """
          def s = params._source;
          if (s == null) { emit(false); }
          else { emit(s.containsKey("__versions")); }
        """
      }
    }
  },
  "query": {
    "term": { "has_versions": false }
  },
  "_source": true,
  "size": 10
}

Note

You'll probably have to customize the query above to exclude specific indices that do not have __versions (and should not have __versions) by replacing -excluded_index1,-excluded_index2. In general, any index that is not written to by ElasticGraph should be excluded. These may have names like .kibana_*, .plugins-*, .security* or .opendistro*. In addition, any ElasticGraph derived index (populated using the derive_indexed_type_fields schema definition API) wil not have __versions and should be excluded.

If the query returns no results (after you've excluded the appropriate indices), then you can safely proceed. If results are returned on any non-derived ElasticGraph indices, you're not ready to upgrade to 1.0.0. You'll first need to run a backfill into a fresh index using ElasticGraph 0.19.x with use_updates_for_indexing: true (or with that option omitted to use the default of true). Reach out in the #elasticgraph channel on the Block Open Source Discord server if you need help.

Remove legacy_grouping_schema: true

ElasticGraph 0.17.1.0 introduced an improved Date/Time grouping API. The GraphQL schema for it, while strictly better, was a breaking change for existing GraphQL clients. A backwards-compatibility mode was provided to allow existing ElasticGraph projects to easily upgrade:

t.field "startedAt", "DateTime", legacy_grouping_schema: true

The legacy_grouping_schema option has been removed from ElasticGraph v1.0.0, and if your schema definition uses it, you'll have to go through a multi-step migration process before you can upgrade.

  1. Introduce an aliased field. The field should use an alternate name (e.g. with a Legacy suffix), be graphql_only, and specify a name_in_index of the original field so that it's backed by the existing field in the index:
diff --git a/config/schema/artists.rb b/config/schema/artists.rb
index dbeeef4..b633d7b 100644
---...
Read more

Contributors

myronmarston, thomasmahoney, and dependabot
Loading

v1.0.0.rc4

04 Aug 17:45
@github-actions github-actions
v1.0.0.rc4
d9874b0

Choose a tag to compare

View all tags
v1.0.0.rc4 Pre-release
Pre-release

What's Changed

New Contributors

Full Changelog: v1.0.0.rc3...v1.0.0.rc4

Contributors

myronmarston, thomasmahoney, and dependabot
Loading

v1.0.0.rc3

10 Jul 21:41
@github-actions github-actions
v1.0.0.rc3
7f631b6

Choose a tag to compare

View all tags
v1.0.0.rc3 Pre-release
Pre-release

What's Changed

Full Changelog: v1.0.0.rc2...v1.0.0.rc3

Contributors

myronmarston and dependabot
Loading

v1.0.0.rc2

09 Jul 18:09
@github-actions github-actions
v1.0.0.rc2
7ade6ec

Choose a tag to compare

View all tags
v1.0.0.rc2 Pre-release
Pre-release

What's Changed

Full Changelog: v1.0.0.rc1...v1.0.0.rc2

Contributors

myronmarston and dependabot
Loading

v0.19.3.0

20 Jun 16:30
@github-actions github-actions
v0.19.3.0
cd7a1af

Choose a tag to compare

View all tags
v0.19.3.0

ElasticGraph v0.19.3.0 has been released! This release includes a couple of new features, some bug fixes, and a minor breaking change.

New Feature: Field-level Custom Resolver Arguments

We added a custom GraphQL resolver API in ElasticGraph v0.19.2.0. That release allowed the same resolver class to be used with different parameters by registering it multiple times:

require(require_path = "roll_dice_resolver")
schema.register_graphql_resolver :roll_2_dice,
  RollDiceResolver,
  defined_at: require_path,
  number_of_dice: 2

schema.register_graphql_resolver :roll_3_dice,
  RollDiceResolver,
  defined_at: require_path,
  number_of_dice: 3

schema.on_root_query_type do |t|
  t.field "roll2Dice", "Int" do |f|
    f.resolve_with :roll_2_dice
  end

  t.field "roll3Dice", "Int" do |f|
    f.resolve_with :roll_3_dice
  end
end

ElasticGraph v0.19.3.0 allows you to provide these parameters at the field level when configuring a field to use a resolver:

require(require_path = "roll_dice_resolver")
schema.register_graphql_resolver :roll_dice,
  RollDiceResolver,
  defined_at: require_path

schema.on_root_query_type do |t|
  t.field "roll2Dice", "Int" do |f|
    f.resolve_with :roll_dice, number_of_dice: 2
  end

  t.field "roll3Dice", "Int" do |f|
    f.resolve_with :roll_dice, number_of_dice: 3
  end
end

Improved Apollo Federation Support

Apollo Federation provides a powerful way to combine multiple subgraphs into a single supergraph. ElasticGraph has shipped with the elasticgraph-apollo extension for a long time, which makes any ElasticGraph project plug into an Apollo supergraph as a subgraph.

However, ElasticGraph schemas haven't always lined up with Apollo federation idioms. To expose a reference to an Apollo entity, a subgraph needs to expose an entity reference containing a non-resolvable entity with just the @key fields:

type Product @key(fields: "id", resolvable: false) {
  id: ID
}

The ElasticGraph schema would then expose fields like product: Product or products: [Product!]! rather than productId: ID or productIds: [ID!]!. However, if your schema already has a productId field, migrating to the entity reference can be a significant effort, requiring clients to migrate and a backfill.

ElasticGraph v0.19.3.0 includes a new feature to help out in this situation. Here's how to use it:

# Existing field
t.field "productId", "ID"

# New field defined with the new feature
t.apollo_entity_ref_field "product", "Product", id_field_name_in_index: "productId"

This exposes a Product field backed by the productId field.

You can also use this on a collection of IDs:

# Existing field
t.field "productIds", "[ID!]!"

# New field defined with the new feature
t.apollo_entity_ref_field "products", "[Product!]!", id_field_name_in_index: "productIds"

Or, if you want to provide a paginated collection as a relay connection:

# Existing field
t.field "productIds", "[ID!]!"

# New field defined with the new feature
t.apollo_entity_ref_paginated_collection_field "products", "Product", id_field_name_in_index: "productIds"

Upgrade Notes

This release includes a minor breaking change to the custom GraphQL resolver API added in v0.19.2.0. Previously, this was the API to configure a field to use a custom resolver:

schema.on_root_query_type do |t|
  t.field "rollDice", "Int" do |f|
    f.resolver = :roll_dice
  end
end

In ElasticGraph v0.19.3.0, that's changed slightly:

schema.on_root_query_type do |t|
  t.field "rollDice", "Int" do |f|
    f.resolve_with :roll_dice
  end
end

If your project uses custom resolvers (which is not common), you'll need to update to the new API as part of upgrading ElasticGraph.

What's Changed

New Features

Breaking Changes

Bug Fixes

Other Improvements

Full Changelog: v0.19.2.2...v0.19.3.0

Contributors

myronmarston
Loading

v1.0.0.rc1

03 Jun 21:29
@github-actions github-actions
v1.0.0.rc1
1deea43

Choose a tag to compare

View all tags
v1.0.0.rc1 Pre-release
Pre-release

What's Changed

Full Changelog: v0.19.2.2...v1.0.0.rc1

Contributors

myronmarston and dependabot
Loading

v0.19.2.2

05 May 23:12
@github-actions github-actions
v0.19.2.2
8830db4

Choose a tag to compare

View all tags
v0.19.2.2

Bug Fixes

Full Changelog: v0.19.2.1...v0.19.2.2

Contributors

myronmarston
Loading

v0.19.2.1

25 Apr 00:18
@github-actions github-actions
v0.19.2.1
a6266e3

Choose a tag to compare

View all tags
v0.19.2.1

ElasticGraph v0.19.2.1 has been released. This includes some bug fixes, performance improvements, and other minor changes.

Bug fixes

  • Explicitly depend on base64 since Ruby 3.4 no longer bundles it. by @myronmarston in #481
  • Bug fix: handle GraphQL exception during health checks. by @myronmarston in #488

Performance Improvements

Other Improvements

Dependency Upgrades

The datastore versions we build against have been upgraded:

The following Ruby gems have been upgraded:

The following python packages have been upgraded:

What's Changed

Full Changelog: v0.19.2.0...v0.19.2.1

Contributors

myronmarston and dependabot
Loading