typeorm 0.30 版本即将发布!

2018年12月份,typeorm作者 pleerock 对于typeorm 0.4.0 版本的构想深受用户抵制,包含了很多破坏性变更,于是原地搁浅,三年后的今天,构想中的一部分功能终于得以实现,即将合并入主干分支 0.3.0 ,其中包含了一些0.4.0提到的api变更,nodejs版本 es版本提升,

新增的功能虽然不多,但是非常有用,都是社区期待已久的功能,

1. find relation 支持条件查询

在之前的版本中,我们在find的时候可以通过relation属性join我们想要查询的关联表

userRepository.find({
    relations: ["contacts", "photos", "photos.album"]
})

但是尴尬的是😅,我们无法在relation的表中增加过滤条件,面对这样的过滤条件,只能使用querybuilder github issue,新的版本,终于实现了这个功能,

userRepository.find({
    where: {
        photos: {
            album: {
                name: "profile"
            }
        }
    }
})

并且,在select属性中,也支持了relation的部分字段选择

userRepository.find({
    select: {
        id: true,
        firstName: true,
        lastName: true,
        photo: {
            id: true,
            filename: true,
            album: {
                id: true,
                name: true,
            }
        }
    }
})

还支持了 relation中字段的 order条件

userRepository.find({
    order: {
        photos: {
            album: {
                name: "ASC"
            },
        },
    }
})

终于弥补了相对于prisma的功能缺失,用起来更加方便了

2. relation查询支持join或者query两种选项

join不多说了,原来就是这个样子,新增了query的选项,,通过多个查询完成之前的join操作。在数据量很大时,能明显的提升性能

新增无了😂

虽然东西不是很多,但是在typeorm作者多次重申自己已无力全职维护,号召大家捐款的情况下,有这么大的产出,也确实不容易了,作者曾在置顶issue中提到,如果每个月能有10000美刀的捐款,那么他将会全职维护typeorm,如今三年过去了,据笔者统计,typeorm在opencollective中每个月获得的捐款还不足2000美元,距离目标还有较大距离,笔者能力有限,贡献了几十美刀然而也是杯水车薪,希望将来能有大的公司提供长期捐助。

nestjs ,每个月大约有8000美刀的收入,捐赠的大公司甚至有redhat

各位能帮衬的帮衬一下吧... opencollective

那么现在typeorm还缺什么呢

据笔者观察使用,在终于支持了relation条件查询,relation嵌套select,深层order的情况下,,typeorm还缺的可能就是save时的避免二次查询option了。

想象一下我们正常的一个curd请求,前端传来 primaryId 我们肯定会先数据库查询校验一次,然后修改一下,然后再保存,使用typeorm,逻辑非常清晰简单。。

public async setOrderCompleted(id: number) {
        const order = await this.orderRepository.findOne(id);
        if (!order) {
            throw new HttpException(`no order of ${id}`, 400);
        }
        order.orderStatus = OrderStatus.review;
        order.completedTime = new Date();
        return this.orderRepository.save(order, {reload: false});
    }

然而,现在typeorm中的问题是,在save时会重复进行一次select,,来判断save真正要执行的是 insert 还是 update

Request...
/api/order/set_order_completed
query: SELECT `Order`.`id` AS `Order_id`, `Order`.`orderCode` AS `Order_orderCode`, `Order`.`email` AS `Order_email`, `Order`.`transMoney` AS `Order_transMoney`, `Order`.`payType` AS `Order_payType`, `Order`.`payTime` AS `Order_payTime`, `Order`.`payMoney` AS `Order_payMoney`, `Order`.`completedTime` AS `Order_completedTime`, `Order`.`orderStatus` AS `Order_orderStatus`, `Order`.`captureId` AS `Order_captureId`, `Order`.`refundId` AS `Order_refundId`, `Order`.`isActive` AS `Order_isActive`, `Order`.`createTime` AS `Order_createTime`, `Order`.`updateTime` AS `Order_updateTime`, `Order`.`userId` AS `Order_userId`, `Order`.`orderAddressId` AS `Order_orderAddressId` FROM `order` `Order` WHERE `Order`.`id` IN (?) -- PARAMETERS: [21]
query: SELECT `Order`.`id` AS `Order_id`, `Order`.`orderCode` AS `Order_orderCode`, `Order`.`email` AS `Order_email`, `Order`.`transMoney` AS `Order_transMoney`, `Order`.`payType` AS `Order_payType`, `Order`.`payTime` AS `Order_payTime`, `Order`.`payMoney` AS `Order_payMoney`, `Order`.`completedTime` AS `Order_completedTime`, `Order`.`orderStatus` AS `Order_orderStatus`, `Order`.`captureId` AS `Order_captureId`, `Order`.`refundId` AS `Order_refundId`, `Order`.`isActive` AS `Order_isActive`, `Order`.`createTime` AS `Order_createTime`, `Order`.`updateTime` AS `Order_updateTime`, `Order`.`userId` AS `Order_userId`, `Order`.`orderAddressId` AS `Order_orderAddressId` FROM `order` `Order` WHERE `Order`.`id` IN (?) -- PARAMETERS: [21]
query: START TRANSACTION
query: UPDATE `order` SET `completedTime` = ?, `orderStatus` = ?, `updateTime` = CURRENT_TIMESTAMP WHERE `id` IN (?) -- PARAMETERS: ["2022-02-22T16:54:32.353Z",3,21]
query: COMMIT

明明我在判断实体是否存在时已经查询过了,save时完全可以不再查询,直接使用刚刚查询出来的就可以了,但是typeorm的save仍然会在查询一遍,对于性能强迫症患者来说,,很不友好,, 相关issue

micro-orm 很好的解决了这个问题,希望将来typeorm也能跟上。。

typeorm 因为nest集成度很高的原因,获得了大量nestjs用户的关注,作者仍然很努力的去维护他,prisma micro-orm 也吸引了很多用户,然而笔者还是比较推荐typeorm,因为 prisma的 schema 很怪异,micro-orm没有什么亮点。。

typeorm 已经有了完整的嵌套事务、乐观锁、数据迁移、数据模型同步等等必要性功能支持,而其他的小小的语法的易用性上面,可以慢慢的进行追逐。。在nestjs框架如日中天的今天,typeorm的受关注度只会越来越高,而不会越来越少。。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,734评论 6 505
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,931评论 3 394
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,133评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,532评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,585评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,462评论 1 302
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,262评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,153评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,587评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,792评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,919评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,635评论 5 345
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,237评论 3 329
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,855评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,983评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,048评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,864评论 2 354

推荐阅读更多精彩内容