As far as I can tell LLBLGen does not automatically generate relations based on composite foreign keys. The foreign keys in question reference not composite primary keys, but rather composite unique keys. Was that by design or is it something that just has not been implemented yet? I have gone the route of creating custom relations, but it would be nice if that was taken care for me as is the case with basic foreign key relations.

Thanks!

Roman wrote:

As far as I can tell LLBLGen does not automatically generate relations based on composite foreign keys. The foreign keys in question reference not composite primary keys, but rather composite unique keys. Was that by design or is it something that just has not been implemented yet? I have gone the route of creating custom relations, but it would be nice if that was taken care for me as is the case with basic foreign key relations. Thanks!

FK's need a PK side, and unique constraints aren't seen as PK's. So to be able to recognize an FK, the FK has to point to a PK, not a surrogate key which is a unique constraint.

Otis wrote:

FK's need a PK side

This is an assumption made by LLBLGen, correct? Since there is no such requirement on the database side (FK's can point to unique constraints), what was the basis for such an assumption?

Thanks!

Roman, I suspect is the fact that UniqueContraint fields allow NULL values. And some DB's allow duplicate NULL values, PostgreSQL for example:

In general, a unique constraint is violated when there are two or more rows in the table where the values of all of the columns included in the constraint are equal. However, null values are not considered equal in this comparison. That means even in the presence of a unique constraint it is possible to store an unlimited number of rows that contain a null value in at least one of the constrained columns. This behavior conforms to the SQL standard, but we have heard that other SQL databases may not follow this rule. So be careful when developing applications that are intended to be portable.

Roman wrote:

Otis wrote:

FK's need a PK side

This is an assumption made by LLBLGen, correct?

True.

Since there is no such requirement on the database side (FK's can point to unique constraints), what was the basis for such an assumption?

Thanks!

besides NULL values, it also has other smaller problems inside the framework, as the FK isn't the PK of the subtype anymore, and this implies you can change the FK field(s) and make it part of another type. This isn't what inheritance is all about.