Proposal to add validation to srfi-167 and srfi-168 Amirouche Boubekki 05 Aug 2019 15:37 UTC
Re: Proposal to add validation to srfi-167 and srfi-168 Amirouche Boubekki 12 Aug 2019 10:40 UTC

Re: Proposal to add validation to srfi-167 and srfi-168 Amirouche Boubekki 12 Aug 2019 10:40 UTC

Le lun. 5 août 2019 à 17:37, Amirouche Boubekki
<xxxxxx@gmail.com> a écrit :
>
> I had an idea inspired from past discussions about the subject of
> getting together some infrastructure to allow to validate the data
> that is written to the database.

I think I have a good idea of how it should happen.

Unlike what I said previously, okvs-set! and okvs-rm! will not have
hooks mainly because at this level of abstraction, the data is just
bytevectors without notions of lexicographic packing, validating the
raw bytevector is not possible.

In okvs, there will be hooks on transaction start and transaction
commit [0] that abstractions built on top must use to be able to
accomplish among other things validation.

[0] https://htmlpreview.github.io/?https://github.com/scheme-live/srfi-167/blob/master/srfi-167.html#hooks

It will be the responsibility of higher level abstractions to provide
hooks in their mutation procedures that will allow validate and keep
indices synchronized.

I will demonstrate this in nstore, see [1]

[1] https://htmlpreview.github.io/?https://github.com/scheme-live/srfi-168/blob/master/srfi-168.html#hooks

I will also demonstrate how to use the hooks with others abstractions,
my plan is to have the okvs sample implementation come with an example
row store that will enforce uniqueness and column types and maybe
other stuff. It will take time, but it is required to validate that
the approach is good.

Regarding stored procedures, it has always been in my mind that the
okvs library is very low level and that a database must travel with
the code that allows to manage it. It seems to me stored procedures
would work with the current proposal to rely on hooks. I will
demonstrate the use of a stored procedure too.

What I will not do: I will not prescribe a set of validation
procedures. Hooks are extension points that will allow the user to
implement a validation scheme that they think is useful. Otherwise
said, validation will still be optional and by default nstore will be
schema-on-read. Another SRFI could be created to specify what
validation scheme can be used.

Thanks!