V1 prototype

[azazeal]

This PR contains an ambitious prototype that aims to serve as the foundation of the next major version of this package.

This iteration tries to ensure that the behavior of the package is consistent across the different data stores we aim to support. In order to achieve this, this implementation enforces validations against the 3 different types of tokens (buckets, keys & values).

Any literal may be considered a valid bucket if it:

• a) is non-empty (and therefore non-nil).
• b) is up to 50 bytes long.
• c) consists of valid UTF8 encoded runes.
• d) does not end in white space.

Similarly, any literal may be considered a valid key if it:

• a) is non-empty (and therefore non-nil).
• b) is up to 200 bytes long.

And, finally, any literal may be considered a valid value if it:

• a) is not nil.
• b) is up to 16 KiB (or 16,384 bytes) long.

Because of the above, and disregarding the expansion of most functions to also accept a Context, this implementation would only be backwards compatible in scenarios where the above constraints were already respected (even accidentally).

[mohammed90]

There was a discussion at https://github.com/caddyserver/caddy/pull/6097 about these upcoming changes. Given our hard experience with Badger (see linked thread) and the transitive dependencies each driver/database pulls, do you think it's possible to break the drivers from the core? Something akin to what the database/sql package offers. It allows downstream users to determine their desired DB to support and trim their transitive deps. It also avoids build constraints imposed by the drivers (Badger in our case).

[azazeal]

There was a discussion at caddyserver/caddy#6097 about these upcoming changes. Given our hard experience with Badger (see linked thread) and the transitive dependencies each driver/database pulls, do you think it's possible to break the drivers from the core? Something akin to what the database/sql package offers. It allows downstream users to determine their desired DB to support and trim their transitive deps. It also avoids build constraints imposed by the drivers (Badger in our case).

With this implementation, the drivers are broken from the core. For example, unless you import _ "github.com/smallstep/nosql/driver/badger" then you won't end up building the driver for it. You may pick and choose which drivers you want to include, much like database/sql does.

This however, doesn't mean that you won't end up getting the transitive dependencies. To avoid that, we'd have to convert each driver directory in their own Go module (an option I don't believe we're willing to consider) or extract each driver into their own repo/package (e.x. github.com/smallstep/nosqlpgdrv, github.com/smallstep/nosqlmysqldrv, github.com/smallstep/nosqlbadgerdrv & github.com/smallstep/nosqlboltdrv), with the additional overhead this entails.

Your suggestion/request isn't unreasonable, and something that personally I'd like to see addressed, so I'll try to see where the team stands on and take it from there.

Hope this helps.

[mohammed90]

Thank you for the consideration! I understand the maintenance burden. I'll keep an eye on here 🙂

[mohammed90]

I'd hate to be demanding, but can you at least put badger behind a build tag 🙂