supabase / supabase-flutter / 36568174948

94%

push

github

fix(typegen): keep the document order of foreign keys when partitioning relationships (#1894)

## What

`_foreignKeysByColumn` partitions the relationships into "references a
table" and "references a view" with two `where` passes instead of
`List.sort`, so the relative order inside each half is the document
order.

## Why

The partition used `..sort()` with a comparator that returns `0` for
every pair in the same half. `List.sort` is not stable: it is an
insertion sort for up to 33 elements (`right - left <= 32` in
`dart:_internal`) and a dual-pivot quicksort from 34, which reorders
equal elements. The map is then filled with `putIfAbsent`, so when a
column carries more than one foreign key (an overlapping composite key
next to a single-column one, for example) the winner is "whichever one
the quicksort put first" once the schema has 34 or more relationships,
and it can flip when an unrelated relationship is added elsewhere.

`sortGeneratorMetadata` (#1883, mirroring supabase/sdk#207) puts the
relationships in a deterministic order precisely so that the generated
code is stable, and the parser's contract comment says document order is
kept. This is the one step that could still reorder them.

Concrete case, pinned by the test: `books.author_id` has
`books_author_id_fkey` to `authors` first in the document and
`books_author_id_editors_fkey` to `editors` at position 30, with 32
other relationships around them.

| Relationships in the document | `main` | this PR |
|---|---|---|
| up to 33 | `authors` | `authors` |
| 34 | `editors` | `authors` |

## Not a breaking change

No public API changes. For documents whose columns each carry a single
foreign key, or with 33 or fewer relationships, the output is identical.

## Tests

`packages/supabase_typegen/test/generator_metadata_parser_test.dart`:
`the first foreign key on a column wins past the sort threshold`, built
from 34 inline relationships. Fails on `main` (`Expected: 'authors'
Actual: 'editors'`) and p... (continued)

9 of 9 new or added lines in 1 file covered. (100.0%)

8793 of 9639 relevant lines covered (91.22%)

4.95 hits per line