feat(root): introduce schema-seed

[dkropachev]

Statement data and schema seed are the same at the moment.
We need to split them in order to be able to run different data flow on the same schema

[nuivall]

I don't immediately see why splitting is a must. Could you elaborate?

[dkropachev]

I don't immediately see why splitting is a must. Could you elaborate?

Say you want to change payload, but keep the schema, in current implementation you have to provide a schema file.
Better solution would be to split schema seed from payload seed, which allow you to pick schema by schema-seed and pick payload by payload-seed.

As of now we use global Rand instance from rnd to generate it, changing it's seed, which is not straightforward and could be unexpectedly accidentially poisoned.
This PR changes schema generation code to use local instance of rnd.Rand and intrduce --schema-seed command line option.

[nuivall]

If there is an option to provide schema file then I guess it will be different than one generated by seed, so no need to be compatible here.

I think the problem is subtle, and solving it needs to take concurrency into consideration

[dkropachev]

If there is an option to provide schema file then I guess it will be different than one generated by seed, so no need to be compatible here.

Not exactly, when gemini starts it outputs schema it generated, you can take it as it is or updated and feed back to gemini, it allows you to have either exact same schema or something different.
Not quite get compatibility issue, could you please elaborate?

I think the problem is subtle, and solving it needs to take concurrency into consideration

Agree, it is not major issue.
There is no concurency in the schema generation.

[nuivall]

You can but why would you do it? If you want to achieve the same behaviour you need to provide the same seed. In such case you don't need to provide any file because generated schema will be the same anyway.

[dkropachev]

You can but why would you do it? If you want to achieve the same behaviour you need to provide the same seed. In such case you don't need to provide any file because generated schema will be the same anyway.

Ahh, 100% agree, but there is one problem - if we change way schema is generated, change order of invoking rnd.Rand methods or add additional things there, then same schema seed will give different schema, while schema file gives you persistent result.

[nuivall]

Such changes are breaking and need to be announced (once generation is stable, now it doesn't matter much). And you won't achieve the same result if you've changed something the requests likely also will be different.

Moreover this can be alleviated by pinning version of gemini to test run, and it would be a solution covering more cases.

[dkropachev]

Such changes are breaking and need to be announced (once generation is stable, now it doesn't matter much). And you won't achieve the same result if you've changed something the requests likely also will be different.

True, but it does not relate to schema, queries is another topic.

Moreover this can be alleviated by pinning version of gemini to test run, and it would be a solution covering more cases.

Agree.
schema file is option to have persistent schema from version to version
schema seed is option to have persistent schema, but it's persistence could be violated when you move from version to version

[dkropachev]

@nuivall, are you ok with merging it ?