Skip to content

Releases: block/elasticgraph

v0.19.1.1

07 Feb 20:19
@github-actions github-actions
v0.19.1.1
f403175
Compare
Choose a tag to compare
v0.19.1.1 Latest
Latest

ElasticGraph v0.19.1.1 has been released! Upgrading from v0.19.1.0 should require no changes.

What's Changed

Bug Fixes

  • Remove a confusing TODO comment from bootstrapped projects. by @myronmarston in #154
  • Improve app_name validation when running elasticgraph new. by @myronmarston in #155

Dependency Upgrades

The following Ruby gems have been upgraded:

  • aws-sdk-cloudwatch: 1.109.0 -> 1.110.0 in #145
  • aws-sdk-lambda: 1.145.0 -> 1.146.0 in #146
  • aws-sdk-sqs: 1.91.0 -> 1.92.0 in #147
  • aws-sdk-s3: 1.179.0 -> 1.180.0 in #148

Other Improvements

Full Changelog: v0.19.1.0...v0.19.1.1

Contributors

myronmarston
Assets 2
Loading

v0.19.1.0

07 Feb 02:00
@github-actions github-actions
v0.19.1.0
4599d86
Compare
Choose a tag to compare
v0.19.1.0

ElasticGraph v0.19.1.0 has been released! This release includes a new bootstrapping process, some bug fixes, official support for Ruby 3.4, and many dependency upgrades.

New Bootstrapping Process

To bootstrap a new ElasticGraph project, run:

$ gem exec elasticsearch new path/to/dir

It'll generate a project skeleton for you to quickly get you up and running.

New RSpec Shared Example Group

elasticgraph-local now includes an RSpec shared example group which provides a standard set of tests for ElasticGraph projects. Here's an example of what using it looks like (based on what elasticgraph new generates:

require "elastic_graph/local/spec_support/common_project_specs"
require "musical_artists/factories"
require "musical_artists/fake_data_batch_generator"

RSpec.describe "ElasticGraph project" do
  ignored_factories = [
    # List any factories to ignore
  ]

  include_examples "an ElasticGraph project",
    use_settings_yaml: "local.yaml",
    ignored_factories: ignored_factories

  it "generates a batch of valid records from `FakeDataBatchGenerator`" do
    batch = MusicalArtists::FakeDataBatchGenerator.generate(artists: 20, venues: 5)
    expect(batch.size).to eq(25)
  end
end

Upgrade Process

Upgrading from v0.19.0.0 should be easy. There's one breaking change, but it's an easy one to deal with.

The define_fake_data_batch_for block signature has changed. In your Rakefile, look for define_fake_data_batch_for.
In ElasticGraph v0.19.0.0 and before, it looked like this:

tasks.define_fake_data_batch_for :my_dataset do |batch|
  batch.concat(MyElasticGraphProject::FakeDataBatchGenerator.generate_fake_data(100))
end

We no longer call the block with a batch argument--instead, just return the batch of fake data from the block:

tasks.define_fake_data_batch_for :my_dataset do
  MyElasticGraphProject::FakeDataBatchGenerator.generate_fake_data(100)
end

Alternately, you can define a local batch array, fill it, and return it:

tasks.define_fake_data_batch_for :my_dataset do
  batch = []
  batch.concat(MyElasticGraphProject::FakeDataBatchGenerator.generate_fake_people(100))
  batch.concat(MyElasticGraphProject::FakeDataBatchGenerator.generate_fake_companies(100))
  batch
end

What's Changed

New Features

Breaking Changes

Bug Fixes

  • Lazily resolve index.rollover and index.route_with field paths, allowing types to be defined in any order. by @myronmarston in #113, #114, #134
  • Fix elasticgraph-apollo to make it safe to call results multiple times. by @myronmarston in #136

Dependency Upgrades

The following NPM packages have been upgraded:

  • tailwindcss: 3.4.10 -> 3.4.17 in #72
  • @tailwindcss/typography: 0.5.14 -> 0.5.16 in #73, #93

The following Ruby gems have been upgraded:

  • apollo-federation: 3.8.5 -> 3.10.0 in #143
  • aws-sdk-cloudwatch: 1.108.0 -> 1.109.0 in #101
  • aws-sdk-lambda: 1.144.0 -> 1.145.0 in #100
  • aws-sdk-s3: 1.176.1 -> 1.179.0 in #90, #102, #121
  • aws-sdk-sqs: 1.89.0 -> 1.91.0 in #88, #103
  • elasticsearch: 8.17.0 -> 8.17.1 in #99
  • factory_bot: 6.5.0 -> 6.5.1 in #126
  • flatware-rspec: 2.3.3 -> 2.3.4 in #89
  • graphql: 2.4.8 -> 2.4.9 in #120
  • jekyll: 4.3.4 -> 4.4.1 in #119, #122
  • json_schemer: 2.3.0 -> 2.4.0 in #132
  • logger: 1.6.4 -> 1.6.5 in #95
  • ox: 2.14.19 -> 2.14.21 in #96, #118
  • rack: 3.1.8 -> 3.1.9 in #125
  • rubocop-rspec: 3.3.0 -> 3.4.0 in #106
  • standard: 1.41.0 -> 1.44.0` in #87, #98
  • steep: 1.9.3 -> 1.9.4 in #140
  • super_diff: 0.14.0 -> 0.15.0 in #92

Other Improvements

New Contributors

Full Changelog: v0.19.0.0...v0.19.1.0

Contributors

myronmarston, dependabot, and 2 other contributors
Assets 2
Loading

v0.19.0.0

10 Dec 22:53
@github-actions github-actions
v0.19.0.0
79e4a65
Compare
Choose a tag to compare
v0.19.0.0

ElasticGraph v0.19.0.0 has been released! This release includes a change to how we treat empty filter predicates, a number of other bug fixes, and many other small changes.

Changes to Treatment of Empty Filter Predicate

ElasticGraph's filtering API supports what we call empty predicates. An empty predicate is one which contains insufficient information to apply any filtering. This can take many forms:

field: null
field: {}
field: {gt: null}
field: {subfield: {}}
field: {subfield: {equalToAnyOf: null}}

Most of the time, empty predicates show up when using a query with variables. Here's an example:

query FindArtists(
  $names: [String!] = null
  $yearFormed_gt: Int = null
  $albumNames: [String!] = null
) {
  artists(filter: {
    name: {equalToAnyOf: $names}
    bio: {yearFormed: {gt: $yearFormed_gt}}
    albums: {anySatisfy: {name: {equalToAnyOf: $albumNames}}}
  }) {
    nodes {
      name
      bio {
        yearFormed
      }
      albums {
        name
      }
    }
  }
}

This query supports optional filtering using the nullable variables $names, $yearFormed_gt, and $albumNames. Any of these variables that are submitted as null or omitted when submitting the query will result in an empty predicate.

In prior ElasticGraph versions, empty predicates were ignored. Internally, they were pruned out. For example, if a client submitted the above query with {"yearFormed_gt": 2000}, then ElasticGraph would evaluate the query as if it was this:

query FindArtists(
  $yearFormed_gt: Int = null
) {
  artists(filter: {
    bio: {yearFormed: {gt: $yearFormed_gt}}
  }) {
    nodes {
      name
      bio {
        yearFormed
      }
      albums {
        name
      }
    }
  }
}

While this generally worked great, we realized that this treatment breaks some standard boolean algebra laws when an empty predicate shows up inside an anyOf or a not (as detailed in sections below). In ElasticGraph v0.19.0.0, we now treat empty predicates as matching all documents rather than ignoring them outright. In SQL terms, an empty predicate has the value of TRUE (e.g. WHERE field = "abc" AND TRUE). Under an anyOf an empty predicate now acts like an OR TRUE and under a not it acts like a NOT TRUE.

Impact on anyOf

Previously, empty predicates inside an anyOf: [...] were ignored, leaving only the non-empty predicates. The anyOf would match documents (or not) based on the remaining non-empty predicates. If all predicates were empty, the anyOf would be reduced to [], matching no documents as a result.

This behavior was incorrect; filter: A and filter: {anyOf: [A]} must always return the same results, no matter what A is. With the old behavior, filter: emptyPredicate would match all documents while filter: {anyOf: [emptyPredicate]} would match no documents.

The new treatment of empty predicates fixes this: if an anyOf contains an empty predicate, the anyOf will now match all documents (since the empty predicate itself matches all documents).

Note: anyOf: null is not impacted by this--that expression matched all documents before and continues to match all documents in ElasticGraph v0.19.0.0.

Impact on not

Previously, a not: emptyPredicate expression was ignored. However, according to the laws of boolean algebra, filter: A and filter: {not: A} must be complements. Since filter: emptyPredicate matches all documents, filter: {not: emptyPredicate} must match no documents. The new treatment fixes this.

Upgrade Process

During the upgrade process, we recommend that you carefully audit your client queries to see which ones may be impacted by this change in behavior. In general, a query can only be impacted when it allows an empty predicate (either via a literal null or {}, or via a query variable that could have those values) under anyOf or not. Queries which do not use the anyOf or not operators will not be impacted, and queries which do not allow an empty predicate in those locations will not be impacted. Any queries which may be impacted by this change should be verified to be compatible with the new semantics, or rewritten to be compatible with it.

Breaking Changes

  • Remove anyOf and not from Matches(Phrase|Query)FilterInput. by @myronmarston (in pre-public codebase)
  • Improved the indexer_autoscaler_lambda to manage lambda concurrency instead of SQS event source mapping concurrency to allow it to go past 1000. by @akumar1214 in #13, #14
  • Fix filter boolean algebra bugs related to empty predicates under anyOf and not. by @acerbusace in #8, #22, #6, #39, #40, #41

Bug Fixes

  • Fix filter boolean algebra bugs related to empty predicates under anyOf and not. by @acerbusace in #8, #22, #6, #39, #40, #41
  • Validate variables to make sure they are a JSON object as expected. by @myronmarston in #42
  • Handle too_many_buckets_exception more gracefully. by @myronmarston in #44
  • Fix ArgumentError when grouping sub-aggregations on a nullable field. by @myronmarston (in pre-public codebase)

Dependency Upgrades

Other Improvements

New Contributors

Full Changelog: https://github.com/block/elasticgraph/commits/v0.19.0.0

Contributors

myronmarston, acerbusace, and 4 other contributors
Assets 2
Loading

v0.19.0.0.rc2

05 Dec 16:33
@github-actions github-actions
v0.19.0.0.rc2
b81013d
Compare
Choose a tag to compare
v0.19.0.0.rc2 Pre-release
Pre-release

What's Changed

New Contributors

Full Changelog: https://github.com/block/elasticgraph/commits/v0.19.0.0.rc2

Contributors

myronmarston, acerbusace, and 4 other contributors
Assets 2
Loading