Join column named after children when using @ManyToMany on STI parent entity about mikro-orm HOT 9 CLOSED

I hope the fix wont break anything else :D

from mikro-orm.

You don't have to redefine anything, just define the joinColumn on the parent. Redefining relations seems like a bad idea on its own to me.

from mikro-orm.

I literally started crafting a minimal example to create a bug report like this at the same time you were creating yours!

@carlosV2 small world :-)

from mikro-orm.

A workaround is to redefine the @ManyToMany relationship within each child entity and explicitly define the join column:

@Entity({ discriminatorColumn: "type" })
class User {
  @ManyToMany({ entity: () => Privilege })
  privileges = new Collection<Privilege>(this);
}

@Entity()
class SuperUser extends User {
  @ManyToMany({ entity: () => Privilege, joinColumn: "user_id" })
  privileges = new Collection<Privilege>(this);
}

@Entity()
class AdminUser extends User {
  @ManyToMany({ entity: () => Privilege, joinColumn: "user_id" })
  privileges = new Collection<Privilege>(this);
}

from mikro-orm.

I literally started crafting a minimal example to create a bug report like this at the same time you were creating yours!

Anyway, if anyone is interested, this is the minimal example: https://github.com/carlosV2/mo-test

The idea on the example is to have a parent Book entity and 2 child entities extending it (PaperbackBook and HardcoverBook). The name of the books is a many-to-many with Text which has a language field to provide translations.

This example is a super-simplification of a real-life code I'm currently working on.

You can run npm run db to provide yourself a PostgreSQL DB (via docker) and then run npm run app to get the SQL printed in screen.

In my case it yields the following:

create table "book" ("id" text not null, "pages" int not null, "cover" text check ("cover" in ('paperback', 'hardcover')) not null, constraint "book_pkey" primary key ("id"));
create index "book_cover_index" on "book" ("cover");

create table "text" ("id" text not null, "language" text check ("language" in ('en', 'es')) not null, "content" text not null, constraint "text_pkey" primary key ("id"));

create table "book_name" ("hardcover_book_id" text not null, "text_id" text not null, constraint "book_name_pkey" primary key ("hardcover_book_id", "text_id"));

alter table "book_name" add constraint "book_name_hardcover_book_id_foreign" foreign key ("hardcover_book_id") references "book" ("id") on update cascade on delete cascade;
alter table "book_name" add constraint "book_name_text_id_foreign" foreign key ("text_id") references "text" ("id") on update cascade on delete cascade;

Notice how the book_name table has the hardcover_book_id while it should be just book_id.

from mikro-orm.

@B4nan thanks for the improved workaround. I just confirmed that works on the test repo, in my actual project, which uses the PostgreSQL driver, and @carlosV2' repo. I thought that I had already tried that approach and it didn't work, but it seems that there were some other issues in my code that made it fail.

That said, it's still a workaround. I think that the default behavior is unexpected and undesirable.

from mikro-orm.

Of course, it broke one test and I managed to miss that locally, its gonna be a bit harder.

from mikro-orm.

Thank you for jumping on the fix so quickly, @B4nan! I love MikroORM, thanks for all the work you put into it.

from mikro-orm.

Ok, refactored via a132036. The fix was technically breaking, as now we infer the join column names based on the base type, but the previous behavior didn't make much sense and if people want it, they should override this explicitly.

from mikro-orm.