CUBA could manage unidirectional one-to-many relationship easily, which is a not that uncommon case in real-life. Bidirectional has a cost and provides backward navigation to referencing entity that is not necessarily wanted.
For instance in my project we have bank accounts that could be linked to different entities, but only one time, and we want all relationships being independant from each other => so we cannot have a “mapped by” attribute in bank account for each and every entity type it will be linked to.
A simple way to do that in JPA is to use a join table (like for many-to-many relationship), and put a unique constraint on the target column to obtain a unidirectional one-to-many.
The code generated for a many-to-many (which is managed by CUBA but not that truely frequent in real life) and a unidirectional one-to-many is not that different, so this should not be a big deal.
//Many-to-Many
@JoinTable(name = "BUSY_COUNTERPART_BANK_ACCOUNT_LINK",
joinColumns = @JoinColumn(name = "COUNTERPART_ID"),
inverseJoinColumns = @JoinColumn(name = "BANK_ACCOUNT_ID"))
@ManyToMany
protected Set<BankAccount> bankAccounts;
//Unidirectional One-to-Many
@JoinTable(name = "BUSY_COUNTERPART_BANK_ACCOUNT_LINK",
joinColumns = @JoinColumn(name = "COUNTERPART_ID"),
inverseJoinColumns = @JoinColumn(name = "BANK_ACCOUNT_ID", unique = true))
@ManyToMany
protected Set<BankAccount> bankAccounts;
Of course it also means that Studio would not require a mapped-by attribute when defining unidirectional one-to-many.
As a workaround I’m currently creating the index myself like below, while adding it to init-constraints sql (20.create-db.sql), but this is cumbersome.
create unique index IDX_BCBAL_BANK_ACCOUNT_ID on BUSY_COUNTERPART_BANK_ACCOUNT_LINK (BANK_ACCOUNT_ID)
Mike
See the following issue in our bug tracker: