Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve visible columns heuristics regarding composite foreign keys #1016

Open
RFSH opened this issue Sep 6, 2024 · 0 comments
Open

Improve visible columns heuristics regarding composite foreign keys #1016

RFSH opened this issue Sep 6, 2024 · 0 comments
Assignees
Labels
investigation required Requires some initial investigation

Comments

@RFSH
Copy link
Member

RFSH commented Sep 6, 2024

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 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:

  1. If the column is not part of any fks, we will show it as a regular visible column.
  2. 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.

@RFSH RFSH added the investigation required Requires some initial investigation label Sep 6, 2024
@RFSH RFSH self-assigned this Sep 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
investigation required Requires some initial investigation
Projects
None yet
Development

No branches or pull requests

1 participant