Tags: remyrd/crux
Tags
Here's 1.17.1 :) This is a small bugfix release: - [xtdb#1462] Fixing startup on JDK 16 - we now fall back to the LRU cache when we can't use the second-chance cache. Add `--add-opens java.base/java.util.concurrent=ALL-UNNAMED` to use the second-chance cache. - [xtdb#1526] Fixing MySQL migration in 1.17.0 - thanks @yueda27!
Hey folks, here's 1.17.0! 🚀 Highlights include:
- We now keep more index statistics to help with choosing the right query plan - in certain cases with many filters this can change the query plan (and hence the query time) significantly. This change **requires an 'index version bump'** - see below for more details.
- JDBC users are advised to migrate the `tx_events` index to remove the `compacted` column - see below.
- There's one **breaking change**: the removal of the previously deprecated `:full-results?` flag:
```clojure
{:find [e]
:where [...]
:full-results? true}
;; =>
{:find [(pull e [*])]
:where [...]}
```
- The usual array of bugfixes and performance improvements.
When you query Crux, you don't have to worry about the order of your `:where` clauses - Crux checks its index statistics and picks a query plan for you. In this release, we've added more of these statistics so that we can better understand the shape of your data, and hence pick better plans.
In this release, we've added 'HyperLogLog' statistics, which can efficiently approximate the amount of *distinct* values in a large set. We then use these statistics to make better choices when your queries have filters on multiple attributes. Given a choice, we choose to filter first by attributes with a higher proportion of distinct elements (or higher 'selectivity') so that we can reduce the size of intermediate query results as much as possible as early as possible.
As a result, this release contains an **'index version bump'**. This means that you'll need to clear your Crux query indices, and re-index from the transaction log.
In green/blue production settings, we recommend doing this by starting a new cluster of Crux nodes, waiting for them to catch up with the tx-log, switching over, and decommissioning the old nodes. If you've got any questions/concerns about this, please do get in touch via crux@juxt.pro - we're happy to help out.
Prior to 1.17.0, Crux JDBC created an index on its `tx_events` table based on `(compacted, event_key)`. The queries that previously accessed this no longer filter on the `compacted` key, meaning that the index wasn't being used, and ingestion times were negatively affected.
Crux 1.17.0 nodes will attempt to remove this index (`tx_events_event_key_idx`) on startup if it is present, and idempotently create a more suitable index (`tx_events_event_key_idx_2`), based on `event_key` alone. For most databases, this is a table-locking DDL migration, which may mean that the Crux cluster is unavailable for transactions while the index is being created.
If high availability is required, it's advisable for Crux users to run a non-locking variant of this migration offline, at which point Crux will not need to perform its own migration. For example:
- In PostgreSQL, `DROP INDEX tx_events_event_key_idx; CREATE INDEX CONCURRENTLY tx_events_event_key_idx_2 ON tx_events(event_key);`
- In MySQL 5.6+, the index DDL statements [do not take table locks](https://dev.mysql.com/doc/refman/5.6/en/innodb-online-ddl-operations.html).
- In MSSQL, `DROP INDEX tx_events.tx_events_event_key_idx; CREATE INDEX tx_events_event_key_idx_2 ON tx_events(event_key) WITH (
Thanks to [Mateusz Probachta](https://github.com/beetleman) and [Tijs Mallaerts](https://github.com/mallt) for reporting this one!
- (xtdb#1519) Fix NodeOutOfSyncException when submitting an empty tx - thanks @jacobobryant!
- (xtdb#1318) Can now use vanilla `java.util.Map`s in documents - thanks @AlistairONeill
- (xtdb#1462) Can now start Crux on JDK 16 - we recommend adding `--add-opens java.base/java.util.concurrent=ALL-UNNAMED` to preserve JDK <16 cache performance. Thanks @nivekuil!
- (xtdb#1513) Kafka transit now round-tripping `#crux/id`s correctly.
- (xtdb#1506) Remote API clients now support `:in` parameters.
- (xtdb#1479) Kafka doc-store now fails fast if the requested document isn't present.
- (xtdb#960) Transaction function argument docs in aborted transactions are fully evictable.
- (xtdb#1469) Compact the second-chance cache to avoid scanning through a large empty map.
- (#1503) Fix metrics NPE on startup - thanks again @nivekuil!
As always, a big thanks to everyone who's contributed to this release by submitting PRs, raising issues and helping with repros!
Cheers,
Crux Team
Welcome! We've got a good few changes to tell you about in 1.16.0. There are two breaking changes to be aware of, highlighted below: project -> pull, and a `nil` query parameter bugfix. We've renamed `eql/project` to `pull` to keep it consistent with other EDN Datalog databases, and brought it out of alpha. See the [pull documentation](https://opencrux.com/reference/21.04-1.16.0/queries.html#pull) for more details. With this change, we have also deprecated `:full-results?`, for removal in a later release - replace these with `{:find [(pull ?e [*])], ...}`. We've replaced the Crux HTTP server's Jetty dependency with [ring-jetty9-adapter](https://github.com/sunng87/ring-jetty9-adapter) to take advantage of its HTTP/2 support. HTTP/2 should help latency and throughput for large volumes of small queries and other requests. HTTP/2 is now enabled by default in both HTTP and HTTPS connectors. You can additionally provide `:jetty-opts` to the HTTP server module with any additional options to be passed to the Jetty adapter. We've added implementations `DocumentStore` and `CheckpointStore` for Java NIO `FileSystem`, which means that you can now use anything with a `FileSystem` implementation as a document or checkpoint store. One obvious option is the local filesystem itself, but this also extends to anything that can be mounted as a filesystem (e.g. NFS) and (via their [adapter](https://github.com/googleapis/java-storage-nio)) Google Cloud Storage! Check out the [GCS docs](https://opencrux.com/reference/21.04-1.16.0/google-cloud-storage.html) for details of how to get started. * (xtdb#1487, breaking) `:where [[?e :a nil]]` now only binds against documents containing `{:a nil}` - to specify binding against documents containing `:a`, either pass `:where [[?e :a]]` or `:where [[?e :a _]]` * (xtdb#1486) `nil` values passed in the entity position of `:where` clauses sometimes erroneously yielded results. * (xtdb#1456) We ensure that match failures do not cause a Lucene 'latest tx mismatch' error. * (xtdb#1468) We re-use the Lucene IndexWriter between txs to save creating a new one every time. * (xtdb#1316, xtdb#1448) We ensure all KV snapshots are closed before the IndexStore, to prevent use-after-close segfaults. * (xtdb#1471) We use stronger durability for writes to the KV tx-log and document-store. * (xtdb#1387) We've strengthened the contract for document stores to enforce that documents are available to all consumers as soon as submit-docs returns. This enables us to fail faster in the tx-ingester if, for whatever reason, expected documents aren't present in the doc-store. As always, a big thanks to everyone who's contributed to this release by submitting PRs, raising issues and helping with repros! Cheers, Crux Team
Here's 1.15.0!
This release, we've been hard at work improving the experience for Java-based Crux users, introducing a more IDE-friendly transaction API. We've also added the option to have queries return maps, as well as several Lucene module changes.
== Java API (breaking changes and deprecations for Java and Clojure users)
We've made the Java API for submitting transactions much more IDE-friendly in 1.15.0 - you can now construct transactions programmatically through the new `Transaction` APIs:
```java
TransactionInstant txInstant = node.submitTx(Transaction.buildTx(tx -> {
tx.put(CruxDocument.build("alan-turing", doc -> {
doc.put("firstName", "Alan");
doc.put("lastName", "Turing");
}));
}));
node.awaitTx(txInstant, Duration.ofSeconds(1));
CruxDocument turing = node.db(txInstant).entity("alan-turing");
System.out.println(turing.get("firstName")); // => "Alan"
System.out.println(turing.get("lastName")); // => "Turing"
```
Generally speaking, we've replaced usages of Clojure keyword-based maps and lists in the Java API with more strongly typed objects (the Clojure API remains unchanged). Where possible old methods have been deprecated and marked for removal, although there are a few necessary breaking changes outlined below.
For more usage examples, see the [new Transaction documentation](https://opencrux.com/reference/21.02-1.15.0/transactions.html).
Query, for now, continues to use Clojure data structures - these are on the roadmap for improvement in subsequent releases.
Breaking changes:
* On `ICruxAPI`:
* `latestCompletedTx` and `latestSubmittedTx` now return `TransactionInstant` rather than `Map<Keyword, ?>`
* On `ICruxDatasource`:
* `entity` now returns `CruxDocument` rather than `Map<Keyword, ?>`
* `dbBasis` now returns `DBBasis` rather than `Map<Keyword, ?>`
* The `NodeConfigurator` and `ModuleConfigurator` classes have moved to `NodeConfiguration` and `ModuleConfiguration` respectively, so that configurations are values that can be re-used.
* `crux.api.alpha` has been removed.
Breaking changes for Clojure users using Crux via the Java API:
* The Clojure and Java APIs have been decoupled. The various start-node functions in the `crux.api` namespace still return values implementing the same protocols, so all of the functions in `crux.api` still apply, with the same signatures - but they no longer implement the Java interfaces (e.g. `ICruxAPI`), so any Java interop calls on these values have been removed.
* Assuming you use the functions in `crux.api`, you should ensure that you also use the functions in the `crux.api` namespace to start a node (rather than the Java `crux.api.Crux` class)
Deprecations (to be removed in a subsequent release):
* On `ICruxAPI`:
* `db(Map<Keyword, ?>)` -> `db(DBBasis)` or `db(TransactionInstant)`
* `openDB(Map<Keyword, ?>)` -> `openDB(DBBasis)` or `openDB(TransactionInstant)`
* `hasTxCommitted(Map<Keyword, ?>)` -> `hasTxCommitted(TransactionInstant)`
* `awaitTx(Map<Keyword, ?>, Duration): Map<Keyword, ?>` -> `awaitTx(TransactionInstant, Duration): TransactionInstant`
* On `ICruxIngestAPI` (and, by extension `ICruxAPI`):
* `submitTx(List<List<?>>): Map<Keyword, ?>` -> `submitTx(Transaction): TransactionInstant` (so you can continue to pass the result of this to `awaitTx`, `db` and `openDB`)
* On `ICruxAsyncIngestAPI` (and, by extension, `ICruxAPI`):
* `submitTxAsync(List<List<?>>): IDeref<Map<Keyword, ?>>` -> `submitTxAsync(Transaction): CompletableFuture<TransactionInstant>` (though `IDeref` isn't generic in practice)
* On `ICruxDatasource`:
* `withTx(List<List<?>>)` -> `withTx(Transaction)`
== Query return maps
This is another oft-requested feature, for compatibility with Datomic and DataScript!
You can now get Crux to return maps from queries, providing the map keys with `:keys`, `:syms` or `:strs`:
```clojure
;; with these documents transacted
{:crux.db/id :ivan, :user/name "Ivan", :user/id 1, :user/profession :doctor}
{:crux.db/id :doctor, :profession/name "Doctor"}
;; this query
{:find [?name ?profession-name]
:keys [name profession]
:where [[?user :user/id 1]
[?user :user/name ?name]
[?user :user/profession ?profession]
[?profession :profession/name ?profession-name]]}
;; will now return #{{:name "Ivan", :profession "Doctor"}}
```
See the [query documentation](https://opencrux.com/reference/21.02-1.15.0/queries.html) for more details.
== Lucene changes
Bugs fixed in the recently released `crux-lucene` module:
- [xtdb#1399](xtdb#1399) - An intermittent initialisation issue that could prevent a node from starting
- [xtdb#1428](xtdb#1428) - Text searches that relate to multiple entities associated with identical AV pairs did not consistently return multiple independent tuples
- [xtdb#1401](xtdb#1401) Attempting to query an empty node with a Lucene index shouldn't throw an error
- [xtdb#1416](xtdb#1416) The lucene-text-search predicate should accept logic vars for input
== Elsewhere in this release
- [xtdb#1427](xtdb#1427) - now using [Depstar](https://github.com/seancorfield/depstar) to build the uberjar in crux-builder due to Capsule being ['pretty much dead'](puniverse/capsule#135)
21.01-1.14.0 is primarily a bugfix release to fix an eviction bug in …
…1.13.0
Eviction regression in 1.13.0 (action required):
This release contains an optional index version bump to fix an eviction regression, introduced with the index performance improvements in 1.13.0. Some data remained in Crux after an eviction in certain cases - all personally identifiable information continued to be removed correctly, but some metadata remained in the bitemporal query indices.
* If you're upgrading from <1.13.0 directly to this release, you'll need to re-index anyway because of the improvements in 1.13.0 - if you haven't yet upgraded to 1.13.0, it'd be worth upgrading directly to this release.
* If you've already upgraded to 1.13.0, and you know that you put, evict, and re-put the same entity, you'll need to re-index to fix this issue.
* Otherwise, you can specify `{:crux/index-store {:kv-store {:skip-index-version-bump [16 17]}}}` in your config to opt out of this one.
Projection features:
We've also added support for union and recursive queries to the `eql/project` syntax, as well as several custom parameters - `:into`, `:default` and `:limit`. If you have an entity-id in hand, you can also make projections directly, via the new `project` and `project-many` functions, without needing a query. See the [EQL projection](https://opencrux.com/reference/21.01-1.14.0/queries.html#eql-projection) docs for more details.
In a subsequent release, we'll likely be renaming `eql/project` to `pull`, so that Crux queries are more portable between Crux, Datomic and DataScript.
Elsewhere in this release:
* [xtdb#1380] Fix a hang in `entity-history` caused by document hashes not existing in the doc store.
* [xtdb#1381] Ensures that the logback.xml configuration file is included in custom-build deployments - thanks @coyotesqrl!
* Fix to `eql/project` trying to project a non-existent document
As always, big thanks to everyone who's contributed to this release by submitting PRs, raising issues and helping with repros!
Cheers,
Crux Team
Here's 20.12-1.13.0!
In the headlines:
* A new HTTP API, including JSON support (breaking changes for existing HTTP clients)
* A new Lucene module
* Checkpointing for Crux nodes
* And many more - in fact, we've closed ~80 issues/PRs in this release
More details on these below!
Firstly, 1.13.0 contains changes that require us to modify the way we index transactions into the query indices, so this release contains an 'index version bump'. This means that you'll need to clear your Crux query indices, and re-index from the transaction log.
In green/blue production settings, we recommend doing this by starting a new cluster of Crux nodes, waiting for them to catch up with the tx-log, switching over, and decommissioning the old nodes. If you've got any questions/concerns about this, please do get in touch via crux@juxt.pro - we're happy to help out.
Through this index re-structure:
* We now offer native index support (i.e. internally sorted for efficient range scans) for additional value types: byte arrays, Java's `BigDecimal` and `BigInteger`, and java.time's `Duration`, `Instant`, `LocalDateTime`, `LocalDate` and `LocalTime`.
* We've made some significant ingest performance improvements - up to 10-15% in our internal benchmarks.
* We also now use 'transaction id' as the basis for database snapshots, rather than 'transaction time'. This has fixed a few issues and complexities around transactions that happen to be submitted at the same millisecond.
We've also added the ability to pass these transactions directly from `submit-tx` to `db`:
```clojure
(let [tx (crux/submit-tx node [...])]
(crux/await-tx node tx)
(let [db (crux/db tx)]
...
))
```
This is a non-breaking change - the existing arities are also still accepted. We'd now advise you use the map variant, though, to avoid potential confusion when passing multiple `Date`s :)
We've been hard at work on our HTTP API, making it more consistent with the Clojure/Java APIs. You'll now find the endpoints under `/_crux/*` - for more details, see the [REST API documentation](https://opencrux.com/reference/20.12-1.13.0/http.html#rest-api). The new endpoints support JSON responses in addition to EDN and Transit.
This is a breaking change for users previously hitting the HTTP API directly - users who accessed it through the Crux HTTP client are unaffected.
We also now expose the HTTP Ring handler directly, at `crux.http-server/->crux-handler`, so that it can be incorporated within your own HTTP server.
We've released a Lucene module to add full-text search functionality to Crux!
Full setup instructions can be found in the [Lucene documentation](https://opencrux.com/reference/lucene.html), but here's a quick taste:
```clojure
;; submit this in a transaction
[:crux.tx/put {:crux.db/id :ivan, :name "Ivan"}]
;; await, then query
{:find '[?e ?v]
:where '[[?e :crux.db/id]
[(text-search :name "Iv*") [[?e ?v]]]]}
;; => #{[:ivan "Ivan"]}
```
At the moment, this is in alpha and likely to change - we'd love to hear your feedback.
Previously, new Crux nodes joining a cluster needed to replay the transaction log before they could start serving queries. In this release, we've introduced 'checkpointing', where nodes in a cluster collaborate to store regular checkpoints of their query indices in a shared checkpoint store - new nodes can then pull down a recent checkpoint to become available much faster.
We currently support AWS's S3 as a checkpoint store, and expose a protocol for others to implement their own.
To set up checkpointing for your Crux cluster, see the [checkpointing documentation](https://opencrux.com/reference/20.12-1.13.0/checkpointing.html).
We've made Crux more consistent with other Clojure datalog databases by supporting `:in` bindings:
```clojure
(crux/q node
'{:find [?e]
:where [[?e :name ?name]]
:in [?name]
["Ivan" "Petr"]})
```
We'll be removing support for `:args` in a future release.
For a full list of changes in this release, see the [Github milestone](https://github.com/juxt/crux/milestone/20?closed=1)
* Kafka bumped from 2.3.0 to 2.6.0.
* Nippy bumped from 2.15.1 to 3.1.1 - this brings in a number of small changes introduced after the security fix in 2.15.0.
* We've added a [predicate function allow-list](https://opencrux.com/reference/query-configuration.html#fn-allowlist), so that you can restrict what predicates users are allowed to call in queries.
* If using RocksDB, we recommend setting the `MALLOC_ARENA_MAX` environment variable to `2`, to help prevent facebook/rocksdb#4112.
* (xtdb#1197, bugfix) Documents that included quoted lists were inconsistently hashed
* (xtdb#1323, breaking) We've removed the `delete` function on the KV store protocol - this is now called as `(kv/store kv-store {k nil})`, so that upserts and deletes can be processed atomically.
* (xtdb#1327, breaking) Java API - `recentQueries`, `activeQueries` and `slowestQueries` now return an `IQueryState`.
As always, we'd love to hear your thoughts - you can get in touch via our [Zulip channel](https://juxt-oss.zulipchat.com/#narrow/stream/194466-crux), [GitHub Discussions](https://github.com/juxt/crux/discussions), or you can email us at crux@juxt.pro.
Release 20.09-1.12.1 1.12.1 is a bugfix release - as always, for the full list of PRs and issues in this release, head to https://github.com/juxt/crux/releases/20.09-1.12.1. * [xtdb#1114] - Make Crux throw its own `IllegalArgumentException`s, which also implement `IExceptionInfo` * [xtdb#1119] - Fix off-by-one error in `open-tx-log` implementation for `crux.kv.tx-log` * [xtdb#1127] - Fix error in UnaryJoinVirtualIndex when all of the underlying indices were empty * [xtdb#1132] - Java users can now create an ingest-only node using the `NodeConfigurator` Any issues - let us know!
Releasing 1.12.0! Of particular interest: * We've added [aggregations](https://opencrux.com/reference/20.09-1.12.0/queries.html#aggregates) to the query engine - an oft-requested feature! * We've brought Crux's [module system](https://opencrux.com/reference/20.09-1.12.0/configuration.html) up to speed with what Crux's 'unbundling' makes possible. We've done an awful lot of unbundling in the last six months, but the means of configuring Crux has until now remained largely unchanged - this brings the three core components (transaction log, document store and query indices) to the fore. We've also added support for configuring Crux nodes via JSON, and vastly improved the support for Java users. This is a **breaking change** - you'll need to update your calls to `start-node`. For users familiar with pre-1.12.0 configuration, see the [migration guide](https://github.com/juxt/crux/blob/20.09-1.12.0/docs/topo-migration.adoc) for before/after examples. * We've added support for [Azure Blob storage](https://opencrux.com/reference/20.09-1.12.0/azure-blobs.html) to be used as Crux's document store. Big thanks to Henrik Mohr (@luposlip) for this community contribution - thanks Henrik! We're sure you'll agree it makes a great addition to the Crux ecosystem. * JDBC - we've fixed a bug in the creation of some of the JDBC transaction log backends, ensuring that the transaction times are now stored in UTC all the way through for new transaction logs. For existing JDBC users, see below for more details, and our **recommended migration**. For full details of all the PRs and issues included in this release, head over to the [GitHub milestone](https://github.com/juxt/crux/releases/tag/20.09-1.12.0) For some JDBC backends, transaction times were being stored in local-datetime column types. * Crux clusters where all the nodes have the same TZ are unaffected, on the surface - the tx-log contains local dates but these are converted in and out of JDBC by the same offset. * Crux clusters where the nodes have different TZs are vulnerable - the tx-times may have been converted with one TZ on the way in and a different TZ on the way out * Valid times, and other times in users' documents, are unaffected - these are encoded to Nippy before entering the database, and so aren't subject to JDBC's arcane TZ handling. Valid times do default to transaction time where they're omitted, so these _are_ affected, but any fix to the transaction time will fix the errant valid-times too. This fix updated the default H2, MSSQL, MySQL and Postgres `tx_time` columns to use data types that store UTC timestamps. For users that run nodes in multiple TZs (or may do in the future) we recommend a manual, user-applied SQL migration to alter your existing `tx_events` tables. * H2: `ALTER TABLE tx_events ALTER COLUMN tx_time SET DATA TYPE TIMESTAMP WITH TIME ZONE` * MSSQL: You can't change the column type in MSSQL without first dropping and re-creating the 'default' constraint. To find out the name of the constraint: ``` SELECT dc.Name, dc.definition FROM sys.tables t JOIN sys.default_constraints dc ON t.object_id = dc.parent_object_id JOIN sys.columns c ON dc.parent_object_id = c.object_id AND c.column_id = dc.parent_column_id WHERE t.Name = 'tx_events' AND c.Name = 'tx_time' ``` Then: ``` ALTER TABLE tx_events DROP CONSTRAINT <constraint-name>; ALTER TABLE tx_events ALTER COLUMN tx_time DATETIMEOFFSET NOT NULL; ALTER TABLE tx_events ADD CONSTRAINT tx_time_default DEFAULT SYSDATETIMEOFFSET() FOR tx_time ``` * MySQL: `ALTER TABLE tx_events MODIFY tx_time TIMESTAMP NOT NULL` * Postgres: `ALTER TABLE tx_events ALTER COLUMN tx_time TYPE TIMESTAMPTZ USING tx_time AT TIME ZONE 'Europe/London';` (swapping 'Europe/London' for the Crux node's TZ) As always, we'd love to hear your thoughts - you can get in touch via our [Zulip channel](https://juxt-oss.zulipchat.com/#narrow/stream/194466-crux), [GitHub Discussions](https://github.com/juxt/crux/discussions), or you can email us at crux@juxt.pro.
1.11.0 is largely a bugfix release, although we've also added some op…
…erations functions to introspect the queries running on your node.
We'd like to draw your attention to one in particular:
Version 1.11.0 includes an _optional_ index version bump to fix an indexing bug related to entities with an `Integer` entity-ids. If you do use `Integer` entity-ids (`Long` entity-ids are unaffected), you will need to re-index your Crux nodes from the golden stores - you can do this by removing the KV store's `db-dir`, and Crux will rebuild the indices when the node is restarted.
If you know you are not affected by this (if you only use `Long` entity-ids, or you don't use numeric entity-ids at all), you can pass Crux a flag to skip this index version bump:
```clojure
{:crux.node/topology '[...]
:crux.kv-indexer/skip-index-version-bump [12 13]}
```
* xtdb#1049 - fixes a race condition with transaction function execution
* xtdb#1052 - fixes a bug with standalone nodes replaying the transaction log
* xtdb#1044 - upgrades Nippy to 2.15.1 to fix a [remote code execution vulnerability](taoensso/nippy#130). Nippy now disables its support for `Serializable` classes by default - if you do have non-core Java classes in your Crux instance you will need to specify these in an [allow-list](taoensso/nippy#131). Core classes include most of `java.util.Collection`, `java.util.Date`, `java.util.UUID` and `java.net.URI`.
* xtdb#1051 - upgrades next.jdbc to 1.1.582
We've added a number of functions for you to introspect the queries running on your Crux node:
* `(crux/active-queries node)` - shows the queries currently running on your node
* `(crux/recent-queries node)` - shows the queries that have recently finished
* `(crux/slowest-queries node)` - shows the slowest queries to have run on your node
You can configure what these return using the following configuration parameters:
* `recent-queries-max-age` - how long to keep recently ran queries on the query queue (default 5 minutes)
* `recent-queries-max-count` - max number of finished queries to retain on the query queue (default 20)
* `slow-queries-max-age` - how long to retain queries on the slow query queue (default 24 hours)
* `slow-queries-max-count` max number of finished queries to retain on the slow query queue (default 100)
* `slow-queries-min-threshold` - minimum threshold for a query to be considered slow (default 1 minute)
Morning! 1.10.1 is a non-breaking bugfix release - we've fixed a few bugs and wanted to get them released: * xtdb#1001 - Allowing non-Comparable elements in collections * xtdb#1016 - Fix for eql/project on JDBC document stores * xtdb#1019 - Kafka, call to `seek-consumer` was missing a param, affecting consumers picking up from a different location in the topic.
PreviousNext