Sqlite null fix

[hellkite500]

Fix handling of null/nan enteries in hydrofabric.

Changes

• Allow sqlite iterator to read column types per iteratorion
• Check for string "null" in alt_ids when referencing feature by alternative id property

Testing

1. Tested locally, and via local use of the partition generator to generate partitions of huc01 hydrofabric.

Checklist

• PR has an informative and human-readable title
• Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)
• Code follows project standards (link if applicable)
• Passes all existing automated tests
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future todos are captured in comments
• Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
• Reviewers requested with the Reviewers tool ➡️

Target Environment support

• Linux
• MacOS

[PhilMiller]

Does this need to be done for every row returned by the iterator, or just once for the first row we get? Why can/would column types differ from row to row?

[hellkite500]

If the value in a column is NaN, then sqlite3_column_type will report that as a 5 or NULL type. So if the first row contains NaN but other rows have valid data, then all types are reported as NULL. (This is how we discovered this issue...)

Re-checking for each row ensures we get a non-null type if there is valid data in the column in that row.

[program--]

For additional context, sqlite3 has table definitions that include a schema (i.e. PRAGMA table_info(...);), however, when interacting with rows, sqlite does not refer to the types in the table definition, but instead rely on row-local affinity (or something of that nature) to determine types -- so columns do not have a type associated wholly. Hence, the need to check each row.

The other alternative to this (but a bit more involved) is to pull the types from the table definition when an iterator is created. This solution of pulling types on each iteration is a bit quicker to get into the codebase though.

[PhilMiller]

That's the context that was missing. Nels, could you leave a synopsis of that as a comment in the code?

[hellkite500]

80de41f

[PhilMiller]

You've got a typo in your second commit message - 'alt_it' vs 'alt_id', that would make this commit harder to find by searching later

[hellkite500]

You've got a typo in your second commit message - 'alt_it' vs 'alt_id', that would make this commit harder to find by searching later

Third time's a charm, should be fixed now...