SQLite driver

[dkotik]

@roblaszczak, @m110 I hope to contribute an SQLite driver some time this summer. I am opening this issue to collect ideas and to hear suggestions from you and the community. Two questions to kick off:

1. I noticed that all the drivers are in separate repositories, and I find it a bit odd as opposed to keeping them together in the same repo with their own go.mod file. Another project wouldn't be able to use them as they are too specific. Nonetheless, how would like me to go about implementation? Follow the same pattern?
2. I enjoy working with https://github.com/zombiezen/go-sqlite driver. It does not use the standard library sql interfaces and carries SQLite-specific benefits because of it. Also no CGO. Is it ok if I use it for watermill implementation at least initially? I can do an additional standard lib-compatible one later - it should not be hard to re-implement once it is done.

[roblaszczak]

@roblaszczak, @m110 I hope to contribute an SQLite driver some time this summer. I am opening this issue to collect ideas and to hear suggestions from you and the community. Two questions to kick off:

1. I noticed that all the drivers are in separate repositories, and I find it a bit odd as opposed to keeping them together in the same repo with their own go.mod file. Another project wouldn't be able to use them as they are too specific. Nonetheless, how would like me to go about implementation? Follow the same pattern?

I remember discussing with someone who is all "drivers" in one repo in a similar project, and it's a pain 😅
It kinda works now when all drivers are separate, so we'll prefer not to make a precedence.

It's a good question if it should be in https://github.com/ThreeDotsLabs/watermill-sql repo or a separate one - we would need to consider tradeoffs.

2. I enjoy working with https://github.com/zombiezen/go-sqlite driver. It does not use the standard library sql interfaces and carries SQLite-specific benefits because of it. Also no CGO. Is it ok if I use it for watermill implementation at least initially? I can do an additional standard lib-compatible one later - it should not be hard to re-implement once it is done.

@m110 pointed me to https://github.com/walterwanderley/watermill-sqlite - you may take a look at it as a reference, but as far as I understand, it depends on a driver that depends on CGO?

So https://github.com/zombiezen/go-sqlite sounds like a nice alternative! It would be just perfect to not expose details of that library anywhere - so we could eventually swap the driver in the future if possible.

I'm not sure if you know this link, but it could be useful for you: https://watermill.io/docs/pub-sub-implementing/

[AlexCuse]

@m110 pointed me to https://github.com/walterwanderley/watermill-sqlite - you may take a look at it as a reference, but as far as I understand, it depends on a driver that depends on CGO?

This package uses an interesting approach. I guess you just need this and you "bring your own" stdlib compatible connection? Don't see any driver referenced.

modernc.org/sqlite (https://pkg.go.dev/modernc.org/sqlite) is a SQL compatible driver with no cgo dependency that works very well, but I will be looking into the zombiezen package to see what benefits it carries.

[AlexCuse]

Ah I see zombiezen package uses the modernc driver. FWIW I think there's a strong case to use modernc.org driver directly within the primary watermill-sql package for ease of maintenance, but I would be very interested to compare the two using the watermill benchmarks!

[dkotik]

I am moving back to Ukraine, will follow up in a few months.