v4.4.2

Fixes

• upsertGraph() doesn't update models whose given props are unchanged apart from props that aren't written to the database, like props that $formatDatabaseJson() or pickJsonSchemaProperties leave out. They counted as changed, and the update ran the $beforeUpdate() hooks, which could still write e.g. timestamps #546

v3.9.2

Fixes

• upsertGraph() doesn't update models whose given props are unchanged apart from props that aren't written to the database, like props that $formatDatabaseJson() or pickJsonSchemaProperties leave out. They counted as changed, and the update ran the $beforeUpdate() hooks, which could still write e.g. timestamps #547

v4.4.1

Changes

• Strict insertGraph() and upsertGraph() resolve the settings of each relation path once instead of for every model and option, which speeds up large graphs with many relations entries

v4.4.0

Changes

• Add Model.getGraphSettings(), which resolves the strict mode settings of insertGraph() or upsertGraph() for a relation path from the options of a call, with the same rules and defaults as the call itself #537

Fixes

• Strict insertGraph() with added: 'relate' throws a NotFoundError for related models whose ids don't exist, before anything is written, like upsertGraph() does. Since 4.3.0, it related them unchecked, writing keys that point to no row unless a foreign key constraint rejected them #538

v4.3.0

Changes

• Add a strict option to insertGraph() and upsertGraph() that makes graphs say what they mean. Options are given per relation, as root and relations settings for the rows that a graph leaves out (removed), the rows with ids that aren't in their relation yet (added), the rows that stay (kept) and the new rows (created). In strict mode, they replace the per-path options like relate, unrelate and noDelete. See strict mode #429
• Strict graphs throw where other graphs skip or override data: for rows they don't write, for key props that contradict their relations, and for values they don't write that differ from the stored rows. Equal values pass, so fetched graphs can be sent back unchanged #429
• Strict insertGraph() and upsertGraph() are atomic: they run in a transaction, their own unless the query already runs in one, so a database error halfway leaves nothing written. Hooks that run queries need to use context.transaction, or they wait for the transaction, and deadlock on SQLite #477

Fixes

• The typings of the upsertGraph() options declare fetchStrategy, which TypeScript rejected since 1.6.4 added the option #531

v4.2.0

All changes are in the changelog.

Changes

• Running the same patchAndFetch() or updateAndFetch() query a second time, e.g. awaiting it twice, throws. The second run wrote back the row that the first one fetched, undoing other writes in between.

Fixes

• patchAndFetch() and updateAndFetch() with an empty patch return the unchanged model instead of undefined
• asFindQuery() in static after hooks runs the onBuild hooks of the query's context only once

v4.1.0

All changes are in the changelog.

Changes

• On PostgreSQL, JSON field expressions with a single key use -> / ->> instead of #> / #>>, so expression indexes like ((props->>'points')) match them. An index built on the #>>'{key}' form needs to be rebuilt with ->>.

Fixes

• ref().castText() on JSON paths works with mysql2 on MySQL, e.g. in JSON relation joins
• JSON keys with backslashes read the right values on PostgreSQL with standard_conforming_strings off
• In strict mode, editors suggest column names in where({ }), findOne({ }) and having({ })

v4.0.0

Upgrading from 3.x? Start with the migration guide. All changes are in the changelog.

Highlights

• objection is an ES module package, requires Node 20.19 or newer, knex 3.3, MySQL 8 and TypeScript 5.8
• upsertGraph() and insertGraph() are rewritten:
  • they write graphs in dependency order, and move rows between owners and slots without failing
  • they reject conflicting graphs before writing anything
  • #ref and #ref{} work across the whole graph, also below related models
• Static hooks get the result in the shape that the query returns, and withGraphFetched() assigns what afterFind returns
• limit(), offset() and first() in graph modifiers apply per parent by default
• BelongsToManyRelation, for owners that hold an array of keys
• JSON field expressions work on MySQL and SQLite
• The typings check columns against the models in strict mode, and narrow results after select()

3.x keeps getting fixes on the 3.x branch, published under the legacy dist-tag.

v4.0.0-rc.1

First release candidate of objection 4.0. Install with npm install objection@next.

See the changelog and the migration guide for the changes and how to upgrade from 3.x.

v3.9.1

Fixes

• insertGraph() and upsertGraph() reject only after the queries they already started have finished, so a transaction is rolled back after them. Before, rows of these queries could be committed after the rollback on SQLite #336
• upsertGraph() sets the foreign key of a model that a #ref relates into a HasManyRelation or HasOneRelation. Before, the row was left without it, and the id of the owner could be cleared #311
• upsertGraph() with relate and noUpdate writes the foreign keys of models that it relates through a HasManyRelation or HasOneRelation, like it does for BelongsToOneRelation and ManyToManyRelation, instead of leaving them unrelated without an error, as it did since 1.5.0 #355
• upsertGraph() resolves a #ref{} to a value of an existing model, e.g. a foreign key that an inserted related model gives it, once the graph has filled it in. Before, it read the old value, e.g. undefined #356, #378
• upsertGraph() rejects a graph with cyclic references before it writes anything. Before, it still ran the deletes of the rows that the graph leaves out after the rejection, which deleted them without a transaction and failed after the rollback of one, since 1.5.0 #379
• A many-to-many patch() / update() with join table extras and limit() on MySQL and SQL Server writes the extras to the join rows of the related rows that the limit picks when the relation joins through a related column other than the id, instead of to the join rows that refer to other rows by these ids, as it did since 3.8.0 #360