You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a pretty large database that uses temporal tables. For a development subset we are not interested in the whole history.
When subsetting, it's important that the samples from the history tables are sequential and have no gaps. So a random subset will not provide the data needed to test the full behaviour of the application accessing that DB.
It would be necessary to provide a "sequential" subset, using one or more columns for ordering (including asc/desc option) and specifying the size of the subset. In this particular case, a static size (in number of rows) would be better than a percentage.
A nice-to-have would be to match the subset on a table-name pattern. All the history tables live in their own schema so using a pattern like history.* would be nice as it would dynamically adapt to DB changes.
The text was updated successfully, but these errors were encountered:
We have a pretty large database that uses temporal tables. For a development subset we are not interested in the whole history.
When subsetting, it's important that the samples from the history tables are sequential and have no gaps. So a random subset will not provide the data needed to test the full behaviour of the application accessing that DB.
It would be necessary to provide a "sequential" subset, using one or more columns for ordering (including asc/desc option) and specifying the size of the subset. In this particular case, a static size (in number of rows) would be better than a percentage.
A nice-to-have would be to match the subset on a table-name pattern. All the history tables live in their own schema so using a pattern like
history.*
would be nice as it would dynamically adapt to DB changes.The text was updated successfully, but these errors were encountered: