Skip to content

v1.15.0

Choose a tag to compare

@jarichb jarichb released this 13 Oct 13:22
· 28 commits to main since this release
Immutable release. Only release title and notes can be modified.
800553f

Not on PyPI. This release's package still said 1.14.0, so the upload failed and pip install model2data==1.15.0 does 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 binary column holds a short value. binary is 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, blob and bytes columns 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,
    bytea and blob used 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 pk or
    unique column 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
    generated unique test. The commonest source is a reference drawn the wrong way round, such
    as Ref: 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 --days already 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 own unique test
    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