Btw, got this error (which I’ll be able to solve) but I would tend to consider it a bug.

"generateLogicalModel error={\"title\":\"Bad Request\",\"status\":400,\"detail\":\"Table GDT___ACCOUNT contains primary key defined by both naming convention and DB referential integrity\",\"traceId\":\"69ed373830ccb00e\"}"

Don’t see a real reason why I could not keep naming convention along with creating the actual constraints in the db…

@Jan Soubusta bug?

Well, I invented this validation intentionally. For user convenience I could check that DB and naming definitions are identical and in this case accept it. However, in general DB and naming should not be mixed. When you have DB constraints, it is waste of time to define naming conventions. Please, do not forget that naming conventions must not be defined, if default behavior is what user wants. This is valid per column - if 1 of many columns needs custom behavior requiring a naming convention, define naming only on this column and keep other columns unchanged.

Thanks for the answers… I agree that it’s definitely redundant to do both. Perhaps explicitly mentioning this in the docs might be the solution.