Orm.consumeReader<Fact> testingState
|> fun reader -> Orm.executeWithReader testingState None "select * from \"Fact\"" reader |> Result.toResultSeq
which fails since we index beyond the reader results using the size of the column mapping,
columnMapping.Length > (db) Fact Column count, therefore we get an index oob.
Additionally, running "select from \"Fact\"" will return the columns in the order they are in the DB, which is not necessarily what they are in the type. While this is not generally good behavior in a strongly type sense (using instead of enumerating the columns that should actually be grabbed) it does reveal a fairly big hole in our API's workflow (consumeReader<^T> |> executeWithReader is only guarenteed to work if you specify the columns you want to bring back, and include nulls in the correct locations for the relation instantiation properly).
IIRC, we fixed this by adding a null to the select. Another approach would be to filter out relations from the columnMapping and grab the values based on the column name instead of by position.
Reader tests runs:
which fails since we index beyond the reader results using the size of the column mapping,
columnMapping.Length > (db) Fact Column count, therefore we get an index oob.
Additionally, running "select from \"Fact\"" will return the columns in the order they are in the DB, which is not necessarily what they are in the type. While this is not generally good behavior in a strongly type sense (using instead of enumerating the columns that should actually be grabbed) it does reveal a fairly big hole in our API's workflow (consumeReader<^T> |> executeWithReader is only guarenteed to work if you specify the columns you want to bring back, and include nulls in the correct locations for the relation instantiation properly).
@Zalarian thoughts?