[BUG] SQL Export inverts Foreign Key cardinality (Visual vs SQL mismatch)

[one-centavo]

Describe the bug
I noticed a discrepancy between the visual diagram and the exported SQL code. In the ERD, the relationship is correctly set (1:N), but the generated SQL tries to add the Foreign Key to the parent table instead of the child table.

Update: I found that the SQL output depends on the connection order (starting from the child table to the parent table works, but not vice versa). However, the UI still shows the cardinality labels (1:N) in a way that doesn't always match the generated constraints.

To Reproduce
Steps to reproduce the behavior:

1. Create two tables (e.g., members and memberships).

2. Establish a 1:N relationship by dragging the primary key from the parent table to the child table.

3. Open the relationship settings and observe that the "Primary" and "Foreign" table assignments are swapped (e.g., the child table is listed as Primary).

4. Export the schema to SQL.

5. Observe the output: The ALTER TABLE statement points to the wrong table.

Example

• Visual: members (1) ---- (n) memberships

• Generated SQL: ALTER TABLE members ADD FOREIGN KEY(id) REFERENCES memberships(member_id)

• Expected SQL: ALTER TABLE memberships ADD FOREIGN KEY(member_id) REFERENCES members(id)

Screenshots

Desktop (please complete the following information):

• OS: Linux Mint 22.3
• Browser: Brave
• Environment: Local development (self-hosted)

I'm happy to provide more information or test a fix if needed. Great tool otherwise!