Re: bunsen (re)design discussion #0: list of topics, review of terminology

["Serhei Makarov" <me@serhei.io>]

On Fri, Apr 8, 2022, at 9:56 PM, Frank Ch. Eigler wrote:
> Hi -
>
>> > Test suite. We've touched on this before, and I just want to reiterate:
>> > THIS IS VITAL to prevent someone (realistically *me*) from breaking
>> > your work. [...]
>
> That should be straightforward with the new git/sqlite scheme too.
> One can freeze a git repo for fixed testing, or one can edit one
> under testsuite control.  And one can easily query the resulting
> datasets for expected values.  Should be no problem at all for at
> least the analysis side of the house.
Sure, indeed sticking a frozen sample db into the testsuite might
be essential if we end up designing a schema that is an API,
then end up evolving the schema in a way that requires migrations,
then an existing copy of the db will be an important data source
to test against.

On the other hand, if the db is a purely transient structure
(we can always re-create it from either pure or indexed testlog data,
and 'migration' amounts to re-creating any analysis structures that
are obsolete) then need to test against a frozen db is somewhat less.
Step 1 of the testing is then to create a db, then run various tests
against it. That is, if the implied design promise that db-regeneration is
indeed quick and easy pans out on larger datasets :-P

In any case, after digesting Frank's sample code for sqlite migration,
I have a clearer idea of what pieces to adopt in a way that keeps
continuity with the existing functionality.
I'll do my own quick-experiment-in-a-separate branch to clarify
what I want from the structure.

-- 
All the best,
    Serhei