Why does M:N have owning side?

I’m used to modeling m:n relationships bidirectionally, where the convention may be that two foreign keys are in alphabetical order.

MikroORM seems to have a limitation that only the “owning” side collection changes can be picked up by the ORM. See code from ChangeSetComputer below.

  private processReference<T extends AnyEntity<T>>(changeSet: ChangeSet<T>, prop: EntityProperty<T>): void {
    const isToOneOwner = prop.reference === ReferenceType.MANY_TO_ONE || (prop.reference === ReferenceType.ONE_TO_ONE && prop.owner);
    // why do we have prop.owner?
    if (prop.reference === ReferenceType.MANY_TO_MANY && prop.owner) {
      this.processManyToMany(changeSet, prop, changeSet.entity[prop.name as keyof T] as unknown as Collection<T>);
    } else if (isToOneOwner && changeSet.entity[prop.name as keyof T]) {
      this.processManyToOne(prop, changeSet);
    }

As a result, if you have Book and BookTag models in a m:n relationship with Book as the owner, you could add do:

book.tags.add(myTag)
em.flush()

But this would not work as expected:

myTag.books.add(book)
em.flush()

What was the reason for this limitation?

[lookfirst]

@B4nan … @stephenh and I worked together on Apache Jakarta projects back in the day… probably virtually known each other for 20 years now. 😉

[stephenh]

the thought that tests deviate from production seems really wrong

Well, pedantically yes, but I think reality is more nuanced than that. Even things like validation rules running in a different order (because we tested each one in isolation but in production the code loads a slightly different set of entities, in a different order, or from a different loader method) can matter and just realistically are not exhaustively tested.

To a certain extent, any time we make an abstraction (say a validation rule or even some business logic), the goal is to be able to re-use that abstraction in N places. However, we don’t re-test that abstraction in all N places it’s used; that’s part of the point of the abstraction, to provide “guaranteed to work” functionality.

However, that means the contract between the caller-of-the-abstraction and the abstraction itself needs to be well defined, which is generally what we rely on static typing to do, but “side effect-y” things can throw this off, of which this constraint of “collections must be init’d” is a great example (i.e. “I had unit tested validation rule x/y/z really well, but in the 3rd of 6 places that load this entity, you forgot to pass me the domain object with all of its collections init’d”).

…anyway, sorry for the overly-long/freshly-caffeinated reply. 😃