Repository navigation
v1.15.0
Not on PyPI. This release's package still said 1.14.0, so the upload failed and
pip install model2data==1.15.0does not exist. These fixes ship in 1.16.0.
Byte columns get short hex values, and a key that references a column with too few distinct values now caps its table instead of failing its own unique test. Both were found by running ERD Studio's DBML export through model2data. Some models generate different data for the same seed: see Upgrading below.
Fixed
-
A
binarycolumn holds a short value.binaryis also the name of a Faker provider, and
the generic fallback called it, which returns a whole MiB of random bytes per value: about 3 MB
of text per CSV cell. A 50-row table with two binary hash keys wrote a 391 MB seed that dbt's
seed loader refused outright.binary,varbinary,bytea,blobandbytescolumns now
hold 16 random bytes from the seeded stream, written as 32 hex characters (an MD5-sized hash
key), and stay unique when they are a key. The seed column loads as VARCHAR.varbinary,
byteaandblobused to fall back to placeholder text and no longer appear among the
generic-fallback columns. -
A key that references a column with fewer distinct values caps its table. A
pkor
uniquecolumn referencing another table's column takes each parent value once, so a table
asked for more rows than that column holds distinct values repeated some, and failed its own
generateduniquetest. The commonest source is a reference drawn the wrong way round, such
asRef: dim_product.product_key > fct_order.product_key. The table now gets one row per
distinct parent value, and the summary says so:⚠️ Tables generated with fewer rows than asked, so a unique reference keeps one row per parent value: - dim_product: 35 rows, not 50 (product_key is a unique reference to fct_order.product_key, which holds 35 distinct value(s))This is what
generate --daysalready does when a one-to-one reference runs out of parents.
A self-reference, or a reference into a table generated later in a cycle, is not capped.
Upgrading
Output changes for the same seed in two cases:
- A table with a byte column (
binary,varbinary,bytea,blob,bytes): the byte
column's values, and the values of the columns drawn after it in that table. Its ids, its null
pattern and every other table are unchanged. - A table whose key references a column short of distinct values: it has fewer rows, and the
tables that reference it draw from those rows. These runs failed their ownuniquetest
before, so no passing project is affected.
A model with neither writes the same bytes as in 1.14.0. Committed fixtures from 1.14.0 that
include a byte column will differ when regenerated. Pin model2data==1.14.0 (or the Action's
version: 1.14.0) to keep them, or regenerate and commit the new ones.
Full changelog: v1.14.0...v1.15.0