Every time a component of a blueprint is edited, a new row is inserted into the store. However, because blueprint entries are stored as timeless, we have no way to garbage-collect the obsolete rows. This means every blueprint store ultimately grows unbounded.
Additionally, our current serde-field approach treats the entirety of a data-blueprint for a spaceview as a single atomic element. This means in pathological circumstances such as having huge number of entities each edit to the space-view can result in the addition of a multi-megabyte data-element to the store.
In addition to to the wasted space, this pathologically combines with #3097 to cause a crash once the aggregate size of all blueprint edits exceeds 1GB.
Also related to:
Every time a component of a blueprint is edited, a new row is inserted into the store. However, because blueprint entries are stored as timeless, we have no way to garbage-collect the obsolete rows. This means every blueprint store ultimately grows unbounded.
Additionally, our current serde-field approach treats the entirety of a data-blueprint for a spaceview as a single atomic element. This means in pathological circumstances such as having huge number of entities each edit to the space-view can result in the addition of a multi-megabyte data-element to the store.
In addition to to the wasted space, this pathologically combines with #3097 to cause a crash once the aggregate size of all blueprint edits exceeds 1GB.
Also related to: