CHANGELOG
- new virtual column decorator (#9339) (d305e5f), closes #9323 typeorm#9323 typeorm#9323 typeorm#9323 typeorm#9323
- support for TypeScript 4.8 (#9106) (d924b70), closes /github.com/microsoft/TypeScript/issues/49461#issuecomment-1154443477
- we do not call JSON.stringify() to json/jsonb column types in Postgres. Instead, we delegate value directly to underlying pg driver. This is a correct way of handling jsons.
- array: true must be explicitly defined for array json/jsonb values
- strings being JSON-stringified must be manually escaped
Changes in the version includes changes from the
next
branch and [email protected]
version. They were pending their migration from 2018. Finally, they are in the master branch and master version.- compilation
target
now ises2020
. This requires Node.JS version14+
- TypeORM now properly works when installed within different node_modules contexts (often happen if TypeORM is a dependency of another library or TypeORM is heavily used in monorepo projects)
Connection
was renamed toDataSource
. OldConnection
is still there, but now it's deprecated. It will be completely removed in next version. New API:
export const dataSource = new DataSource({
// ... options ...
})
// load entities, establish db connection, sync schema, etc.
await dataSource.connect()
Previously, you could use
new Connection()
, createConnection()
, getConnectionManager().create()
, etc. They all deprecated in favour of new syntax you can see above.New way gives you more flexibility and simplicity in usage.
- new custom repositories syntax:
export const UserRepository = myDataSource.getRepository(UserEntity).extend({
findUsersWithPhotos() {
return this.find({
relations: {
photos: true
}
})
}
})
Old ways of custom repository creation were dropped.
- added new option on relation load strategy called
relationLoadStrategy
. Relation load strategy is used on entity load and determines how relations must be loaded when you query entities and their relations from the database. Used onfind*
methods andQueryBuilder
. Value can be set tojoin
orquery
.join
- loads relations using SQLJOIN
expressionquery
- executes separate SQL queries for each relation
Default is
join
, but default can be set in ConnectionOptions
:createConnection({
/* ... */
relationLoadStrategy: "query"
})
Also, it can be set per-query in
find*
methods:userRepository.find({
relations: {
photos: true
}
})
And QueryBuilder:
userRepository
.createQueryBuilder()
.setRelationLoadStrategy("query")
For queries returning big amount of data, we recommend to use
query
strategy, because it can be a more performant approach to query relations.- added new
findOneBy
,findOneByOrFail
,findBy
,countBy
,findAndCountBy
methods toBaseEntity
,EntityManager
andRepository
:
const users = await userRepository.findBy({
name: "Michael"
})
Overall
find*
and count*
method signatures where changed, read the "breaking changes" section for more info.- new
select
type signature inFindOptions
(used infind*
methods):
userRepository.find({
select: {
id: true,
firstName: true,
lastName: true,
}
})
Also, now it's possible to specify select columns of the loaded relations:
userRepository.find({
select: {
id: true,
firstName: true,
lastName: true,
photo: {
id: true,
filename: true,
album: {
id: true,
name: true,
}
}
}
})
- new
relations
type signature inFindOptions
(used infind*
methods):
userRepository.find({
relations: {
contacts: true,
photos: true,
}
})
To load nested relations use a following signature:
userRepository.find({
relations: {
contacts: true,
photos: {
album: true,
},
}
})
- new
order
type signature inFindOptions
(used infind*
methods):
userRepository.find({
order: {
id: "ASC"
}
})
Now supports nested order by-s:
userRepository.find({
order: {
photos: {
album: {
name: "ASC"
},
},
}
})
- new
where
type signature inFindOptions
(used infind*
methods) now allows to build nested statements with conditional relations, for example:
userRepository.find({
where: {
photos: {
album: {
name: "profile"
}
}
}
})
Gives you users who have photos in their "profile" album.
FindOperator
-s can be applied for relations inwhere
statement, for example:
userRepository.find({
where: {
photos: MoreThan(10),
}
})
Gives you users with more than 10 photos.
boolean
can be applied for relations inwhere
statement, for example:
userRepository.find({
where: {
photos: true
}
})
- minimal Node.JS version requirement now is
14+
- drop
ormconfig
support.ormconfig
still works if you use deprecated methods, however we do not recommend using it anymore, because it's support will be completely dropped in0.4.0
. If you want to have your connection options defined in a separate file, you can still do it like this:
import ormconfig from "./ormconfig.json"
const MyDataSource = new DataSource(require("./ormconfig.json"))
Or even more type-safe approach with
resolveJsonModule
in tsconfig.json
enabled:import ormconfig from "./ormconfig.json"
const MyDataSource = new DataSource(ormconfig)
But we do not recommend use this practice, because from
0.4.0
you'll only be able to specify entities / subscribers / migrations using direct references to entity classes / schemas (see "deprecations" section).We won't be supporting all
ormconfig
extensions (e.g. json
, js
, ts
, yaml
, xml
, env
).- support for previously deprecated
migrations:*
commands was removed. Usemigration:*
commands instead. - all commands were re-worked. Please refer to new CLI documentation.
cli
option fromBaseConnectionOptions
(nowBaseDataSourceOptions
options) was removed (since CLI commands were re-worked).- now migrations are running before schema synchronization if you have both pending migrations and schema synchronization pending (it works if you have both
migrationsRun
andsynchronize
enabled in connection options). aurora-data-api
driver now is calledaurora-mysql
aurora-data-api-pg
driver now is calledaurora-postgres
EntityManager.connection
is nowEntityManager.dataSource