Suggestion : in Studio let us edit the join table for many-to-many relationship

In Studio, when creating a many-to-many relationship there will be a join table created, but we cannot add fields or constraints to it.

Adding fields would allow us to add association attributes (in design terms) that would de facto transform the association to an entity with a composite PK, which is a perfectly valid mapping. For instance when you link an address to a customer you could define it as a delivery or invoice address using an association attribute.

The current workaround is to create a full-blown entity (costly in dev time and infra resource) or define the kind of address inside the address entity. But in the latter changes the semantic of address entity from “I’m a plain an simple address usable by any process” to “I’m an address used only for delivery or invoicing”.

Adding constraints would allow us to manage cases not currently managed by CUBA : unidirectional one-to-many and many-to-one relationships. Which can be handled by setting a unique constraint on one of the join columns.

Not sure I understand your idea. How do you suppose to work with these additional attributes of the linking table?

I am also not sure if I understand the idea. We choose the following approach for n-to-m relations with additional properties:

The n-to-m relation is modeled as a separate entity, in your case CustomerToAddressLink with a reference to customer and address and the attribute addressType. Same time the “standard” n-to-m relation is modeled which references the same database table as the entitiy (CUSTOMER_TO_ADDRESS_LINK). So you can either navigate over the relation (customer.addresses) or over the separate entity (customer.customerToAdressLinks).

If you want to have two (read only) relations customer.deliveryAddresses and customer.invoiceAddresses but only one database table then you could create two database views that do the constraint filtering and specify them as the n-to-m database table.

When we link an address to a customer we define it as invoice or delivery through an association attribute. Why an association attribute ? Because (in our model) the kind of address has a meaning only when it is linked, so it does not belong to customer or address entity. This makes further evolution easier (i.e manage other kinds of addresses).

I’m ok with an association turned into an entity, and I know we can create it ourselves. I just say that Studio could manage it, after all this is just a link, not a real entity per se. And we will certainly not create two links between the two (linking entity + join table) this is overkill.