Dependency management at scale is... hard. One shortcoming on the horizon is that right now only one version of a bundle can be checked out at a time, so if two bundles both depend on a third bundle, but at different versions of the third bundle, things break. With the goal of releases (#172) on the horizon, one way to skin this cat is by introducing a new type of primary key, a composite type in PostgreSQL, that contains both a uuid that is static for the lifespan of the row, and a version identifier (or maybe commit_id) that changes with every commit:
CREATE TYPE versioned_uuid (
uuid uuid,
version semver
);
CREATE TABLE my_versioned_table (
vid versioned_uuid,
whatever text
);
Each commit would modify the pk (and all internal fks) setting the versioned_uuid.version to that of the current commit, thus basically making it a new row with every commit. The outcome would be that two versions of the same bundle could be checked out simultaneously. Anything that depended on the old version of the bundle would continue to function because each commit would basically be a new copy of the bundle's contents. Committed rows become basically immutable, at least that's the objective.
Early stages of the idea, and there is a lot to figure out.
Dependency management at scale is... hard. One shortcoming on the horizon is that right now only one version of a bundle can be checked out at a time, so if two bundles both depend on a third bundle, but at different versions of the third bundle, things break. With the goal of releases (#172) on the horizon, one way to skin this cat is by introducing a new type of primary key, a composite type in PostgreSQL, that contains both a uuid that is static for the lifespan of the row, and a version identifier (or maybe commit_id) that changes with every commit:
Each commit would modify the pk (and all internal fks) setting the
versioned_uuid.version
to that of the current commit, thus basically making it a new row with every commit. The outcome would be that two versions of the same bundle could be checked out simultaneously. Anything that depended on the old version of the bundle would continue to function because each commit would basically be a new copy of the bundle's contents. Committed rows become basically immutable, at least that's the objective.Early stages of the idea, and there is a lot to figure out.