Relationship conditions

[lewispham]

Is your feature request related to a problem? Please describe.
It looks like mikro-orm does not support default conditions for a relationship. At this time, we'll have to pass the condition as init options when we want to load a collection under some conditions.

const errors = await collection.init({
  where: {
    type: "ERROR"
  }
})

It would be ways more convenient to be able to pass the condition beforehand, when we define the relationship for example.
Describe the solution you'd like
Pass the condition as Collection options

  @OneToMany(() => Log, log => log.user)
  errors = new Collection<Candidate>(this, {
    where: {
      type: "ERROR"
    }
  });

Describe alternatives you've considered
Define the condition as relationship definition

  @OneToMany({
    entity: () => Log,
    mappedBy: log => log.user,
    where: {
      type: "ERROR"
    }
  })
  errors = new Collection<Candidate>(this);

[B4nan]

Why don't you use a filter instead? This is exactly the use case for filters, I am not sure if we need more.

[lewispham]

@B4nan Using filters still requires passing filter name into every single query. While my proposed approach requires no further steps. It's also a bit less readable since filter definition is at entity level, not property level.

[B4nan]

You can enable a filter by default...

[B4nan]

There are indeed some gotchas with filters, if you would use them here, they would always join the target relation, while what you are proposing would be applied only if you load the collection, right?

Btw we will need to go with the alternative approach, the second parameter of the constructor is already occupied, and it feels more correct anyway - it is metadata and as such it should be part of the entity definition, a property initializer is a runtime concept - you won't know anything about that unless you create some entity instance.

[lewispham]

There are indeed some gotchas with filters, if you would use them here, they would always join the target relation, while what you are proposing would be applied only if you load the collection, right?

Yes, that's right.

Btw we will need to go with the alternative approach, the second parameter of the constructor is already occupied, and it feels more correct anyway - it is metadata and as such it should be part of the entity definition, a property initializer is a runtime concept - you won't know anything about that unless you create some entity instance.

I think that makes sense. You can consider supporting all query options instead of just where.

  @OneToMany({
    entity: () => Log,
    mappedBy: log => log.user,
    conditions: {
      where: {
        type: "ERROR"
      },
      orderBy: {id: "DESC"},
      limit: 10
    }
  })
  errors = new Collection<Candidate>(this);

[B4nan]

You can already specify orderBy, for limit it would be pretty hard for anything else than the init call, this would require window functions or subquery joins.

[lewispham]

Ah I see. It should be ok with just where and orderBy then.

[lewispham]

Hi @B4nan, is there any chance that this feature will be implemented soon?

[B4nan]

Yes, there is a chance, e.g. when someone sends a PR :]

I will need to prioritize bug fixing in the upcoming weeks and have a short vacation planned too, I won't have time fore feature development.

[lewispham]

Ok I see. Thanks for the info.

[pohnean]

+1