You make me wonder. In this company, they don't use repository's. Everything is in entity and hooks. I wonder if it's worth arguing for putting everything into repository's.

If it’s a syncronous validation, event listeners are okay. If your entity must have a valid relation to another entity, foreign keys are preferred. If this is something complex, you probably should either implement that somewhere else. Options include a) controller method (if it’s a one-time thing) b) repository method (as a part of transaction logic) and c) stored procedure in the database.

I personally avoid stored procedures, they’re hard to keep under version control and debugging is far from simple. Also calling it reqiures use of raw sql and the code is not exactly TypeORM-style (uses createQueryRunner on connection), but if you feel it appropriate for your case – why not…

I usually start from plain entities and all queries built inside controller methods. At some point, if project grows, certains patterns and repeated queries appear across code base, and copy-pasted code makes it harder to update, and to move forward. That’s where I take a break and refactor to create a repository. Usually it starts from a single repository for a single, most heavily used entity, and if project continues to grow, later repositories get added and more refactoring is done.

Of course, in a small project adding repositories is classic over-engineering…

Thanks for the detailed suggestions.

Our entities are updated via Controllers (for REST endpoints), but also through a bunch of internal Consumers from various pub-sub channels. So all our "validations" are as Event Listener hooks on the entity. And these validations sometimes query the database.

So I think it's a safe place to have the validations. Same thoughts for me about the stored procedures.

So the problem with Transactions and Entity Listeners is that there is no way to access transaction entityManager from inside Entity Listener hooks, so they are outside transaction if they need to query the database.

Pleerock suggests using Entity Subscribers for such cases when you need to query the database within the same transaction. I see that there's a PR related to this here: https://github.com/typeorm/typeorm/pull/4554

https://github.com/typeorm/typeorm/pull/5336#issuecomment-578705790

This is rather amusing.

sir what you want from russian comuniti?

оу, привет!

👋

ого

It's not my PR. :)

👋

open source is tough 🙂

Same conflicts happen in closed source too, it's just they are not visible to outside world :p. But yeah it could have been solved easier if they worked in the same office.

      class RequestParam {
        @IsNotEmpty()
        @Expose()
        id!: string;
      }
      class Request {
        @ValidateNested()
        @Expose()
        params!: RequestParam;
      }

      const errors = await validate(plainToClass(Request, request, { excludeExtraneousValues: true }));
      console.log('* errors', errors); // prints []

I wonder what's the issue here.

      class RequestParam {
        @IsNotEmpty()
        @Expose()
        id!: string;
      }
      class Request {
        @ValidateNested()
        @Expose()
        params!: RequestParam;
      }

      const errors = await validate(plainToClass(Request, request, { excludeExtraneousValues: true }));
      console.log('* errors', errors); // prints []

Seems like this is required:

        @Type(() => RequestParam)

Всем привет! Подскажите пожалуйста как сделать фильтр для where который не будет учитывать регистр.
Есть функция которая возвращает фильтр с Like который заимпорчен из typeorm
return {
    name: Like(%${eventSearchName}%),
};
но она учитывает регистр букв, нашёл информация что можно использовать ILIKE но не пойму как переделать функцию под него, что бы возвращать обьект.

база какая?