My scenario is the following (I haven’t tested it in other combinations):
create an entity with 'generateDdl': false, and in my case it is also a dbView
extend the User entity and mark it as replace parent
create a MANY_TO_MANY relation in the extended User entity
Tested with Studio 6.9.5 and the same CUBA version.
Now create DB scripts, and notice that the alter table SEC_USER and update SEC_USER statements has been added to 10.create-db.sql, but the join table has not been scripted.
It shouldn’t matter the 'generateDdl': false attribute in cases like this, because the many to many join table can be created even between two dbViews, and its init/update DDL statements should always be generated.
There’s one important catch to consider: you cannot create a FK constraint targeting a VIEW.
Anyway I think that Studio should handle this scenario better, for example:
if none of the targets is a dbView, it can safely proceed generating both the FKs targeting the 2 tables
if one or both of them are dbViews it can:
simply warn the user, and ask if they want to continue anyway (without one or both the FKs contraints, leading to a potentially broken referential integrity)
OR
warn the user as before, but optionally generate a TRIGGER (in the corresponding DBMS dialect) dealing with the referential check, and raising a custom exception the framework could easily recognize as a FK violation
Even the first option is better than the current situation (no DDL generation at all). Personally I’m going with the second option (the performance implications in my case are negligible).