When we initially implemented the heuristics for visible columns, we didn't try to optimize it for composite foreign keys. These foreign keys are always added to the end of the visible columns list. But when a column is involved in multiple foreign keys, recordedit cannot correctly handle this scenario. So, the heuristics will always be invalid for entry contexts, and we would have to add annotations for them.
In this issue, we want to summarize the improvements we could make to the existing heuristics.
Details
As part of the visible columns heuristics, we go through each column:
If the column is not part of any fks, we will show it as a regular visible column.
If the column is part of one or multiple fks, go through the fks (sorted by their constraint name):
2.1. If the fk is simple, we create an outbound visible column for it.
2.2. If the fk is composite,
If it’s not an entry context, and the column is not part of any simple fks, we'll add it to the list of visible columns.
Keep track of the composite fk so it can be added in the end.
Instead of adding all the foreign keys in the entry context, we could apply similar checks that we did for prefill as described here and only add the superset foreign key.
This description is not finalized and is pending more investigation. This change could potentially cause issues for the "add related" logic.
Summary
When we initially implemented the heuristics for visible columns, we didn't try to optimize it for composite foreign keys. These foreign keys are always added to the end of the visible columns list. But when a column is involved in multiple foreign keys, recordedit cannot correctly handle this scenario. So, the heuristics will always be invalid for
entrycontexts, and we would have to add annotations for them.In this issue, we want to summarize the improvements we could make to the existing heuristics.
Details
As part of the visible columns heuristics, we go through each column:
Instead of adding all the foreign keys in the entry context, we could apply similar checks that we did for prefill as described here and only add the superset foreign key.
This description is not finalized and is pending more investigation. This change could potentially cause issues for the "add related" logic.