はじめに
TypeScriptでのORM選択時の一大候補、TypeORM。
デコレーターでスキーマ定義、ActiveRecordスタイル、ダウンロード数。
そのどれもが魅力的である。
しかし、TypeORMにはいくつか落とし穴がある。
ここでは私が思い出せる限りの問題と、その対処法を並べていく。
Entity定義
問題
公式のサンプルのようにEntityを定義するとうまく行かない。
@Entity()
class User extends BaseEntity {
@PrimaryGeneratedColumn()
id: number;
@Column()
name: string;
}
idもnameもコンストラクタで初期化されていないため、VSCodeが赤線で怒ってくる。
対処法
@Entit()
class User extends BaseEntity {
@PrimaryGeneratedColumn()
- id: number;
+ id!: number;
@Column()
- name: string;
+ name!: string;
}
!つけて回避できる。
create関数の引数型
問題
レコードを作るときの書き方は大体二通りだろう。
// newする。
const user = new User();
user.name = 'name';
await user.save();
// create関数を使用する。
await User.create({name: 'name'}).save();
注意すべきは、このどちらも、初期化漏れを許容することだ。
newする方は代入忘れを防ぐ方法がなく、create関数に渡す初期化子はPartialになっている。
それはつまり、
@Entity()
class User extends BaseEntity {
@PrimaryGeneratedColumn()
id!: number;
@Column()
name!: string;
+ @Column()
+ email!: string;
}
のように新しいカラムを足しても、型は警報を鳴らすことなくビルドが成功し、save()時にnot null制約に引っかかるということだ。
対処法
二通りある。
コンストラクタ
@Entity()
class User extends BaseEntity {
constructor(name: string, email: string) {
super();
this.name = name;
this.email = email;
}
@PrimaryGeneratedColumn()
id!: number;
@Column()
name: string;
@Column()
email: string;
}
await new User('name', 'example@example.example').save();
これは上手くいくように見えるし、実際一定の条件下では上手くいく。
nameとemailの!も取れているため、コンストラクタでの初期化忘れにも対応している。
しかし、console.logを仕掛けてみるとわかるが、TypeORMはcreateConnection時になんと、一度引数無しで強引にインスタンスを作っているのだ。
それはつまり、上記のコードは一応動くが、厳密にはundefinedが引数として渡されることがある、ということであり、それは、
@Entity()
class User extends BaseEntity {
constructor(props: {name: string, email: string}) {
super();
// ↓でアウト。
this.name = props.name;
this.email = props.email;
}
// ...
}
のように、オブジェクトを引数に取ると、createConnection時にpropsがundefinedの状態で呼び出され、undefined.nameで死ぬということだ。
引数オブジェクトに対するアクセスは許されない。
これの対処法は、propsをoptionalにしてチェックをするということだが、これではコンストラクタでnameやemailを初期化していないケースが存在することになり、nameとemailに!が舞い戻ることになる。
@Entity()
class User extends BaseEntity {
constructor(props?: {name: string, email: string}) {
super();
if (props == null) return;
this.name = props.name;
this.email = props.email;
}
@PrimaryGeneratedColumn()
id!: number;
@Column()
name!: string;
@Column()
email!: string;
}
そしてoptionalにするということは、
await new User().save();
ができるようになるということだ。
ぐぬぬ。
build関数を自作
TypeORMのcreateが信用できなければ、ラッピングすれば良い。
@Entity()
class User extends BaseEntity {
static build = (props: {name: string, email: string}) => User.create(props);
// ...
}
await User.build({name: 'name', email: 'example@example.example'}).save();
当然だが、上手くいく。
定義が面倒だということ以外に目立った欠点はないだろう。
すべきだ。
関連
eager-and-lazy-relationsを使いさえすれば、この項目は無視できるかもしれない。
しかしパフォーマンスを気にしだすと途端に苦しくなる。
この項目ではUserがProfileを持っていると仮定する。
こんな具合だ。
@Entity()
class User extends BaseEntity {
@OneToOne(() => Profile)
readonly profile!: Profile;
}
型ずれ
問題
普通にfindした場合、
const user = await User.findOne()!;
user.profile;// type: Profile, real: undefined
関連は読み込まれないので、user.profileはundefinedなのだが、型はProfileだ。
言うまでもなく危険である。
対処法
これを回避するためには、
@Entity()
class User extends BaseEntity {
@OneToOne(() => Profile)
- readonly profile!: Profile;
+ readonly profile?: Profile;
}
のように、profileをoptionalにすれば良いのだが、それはそれで、
const user = await User.findOne({relations: ['profile']})!;
user.profile;// type: Profile | undefined, real: Profile
const userProfile = user.profile!;
のようになるため、読み込んだ後の使い勝手が悪いが、仕方ないだろう。
読み込み
問題
const user = await User.findOne({relations: ['profile']})!;
気をつけてほしい。
タイポは致命的だ。
relationsはstring[]だ。
relationsはstring[]なのだ。
それはつまり、こう書いてもコンパイルは通るということだ。
const users = await User.find({relations: ['プロフィール']});
ぐぬぬ。
対処法
わからない。
Webpack使用時の循環参照
問題
私はTypeORMをNext.jsと一緒に使っていたのだが、production環境の時だけエラーが出る事件があった。
結構な時間をかけて調査した結果、原因はこれだった。
TypeORMは関連を定義する時、関連先のEntityをimportする必要がある。
import {Profile} from './Profile';
@Entity()
class User extends BaseEntity {
@OneToOne(() => Profile)
readonly profile!: Profile;
}
それはUser.tsと同様に、Profile.tsでも必要だ。
そしてこれは循環importになり、使用しているビルドツールによってはサポートされていない。
理論上importをimport typeに変更することで修正できるが、@OneToOne(() => Profile)の行があるので、スムーズにはいけない。
対処法
-import {Profile} from './Profile';
+import type {Profile} from './Profile';
@Entity()
class User extends BaseEntity {
- @OneToOne(() => Profile)
+ @OneToOne('Profile')
readonly profile!: Profile;
}
@OneToOneに渡すものは文字列でも良いため、これで問題ない。
しかし、文字列だ。
文字列なのだ。
ぐぬぬ。
TypeORMを使用するときは用心すべし
ざっと思い出せる罠はこれくらいだが、とどのつまり、TypeORMの型情報はあまり信用できない。
const user = User.create({name: 'name'});
user.id; // Type: number, real: undefined
await user.save();
user.id; // Type: number, real: number
const user2 = User.find(user.id, {select: ['id']});
user2.name; // Type: string, real: undefined
create後のautogenerateカラムの型ずれは仕方がないにしても、selectはよほどのことがなければ使わないほうが身のためだろう。
最後に
これらの問題は私自身の力量不足や知識不足でTypeORMの力をフルに引き出せず、正しく使えていなかったから引き起こされたという説もある。