Remove dependency on CGO

[kradalby]

This commit changes the SQLite dependency to one that does not depend on
CGO. It uses a C-to-Go translated sqlite library that is Pure go.

• read the CONTRIBUTING guidelines
• raised a GitHub issue or discussed it on the projects chat beforehand
• added unit tests
• added integration tests
• updated documentation if needed
• updated CHANGELOG.md

[juanfont]

Oh! Didn't know about this module. Cool!

[cure]

Oh! Awesome! I didn't know about this library either!

[kradalby]

There is one drawback, I had to set concurrent connections for SQLite to one, I am not sure if that actually has a practical difference as I suspect the whole thing is loaded to memory,

But can't confidently merge it until I have poked around a bit more.

I'll let you know what I'll find and click ready.

[kradalby]

Current state of this, I think I can look a bit more tomorrow:

1. I had a SQLITE_BUSY error based on GORM opening a connection pool and this lib did not support multiple connection out of the box, so I set it to one single connection.

Unanswered question: Does that actually matter in our case?
I would think probably not, I suspect it actually does not affect SQLite performance as much as for example postgres as the DB is likely in memory, we dont use it that heavily and if you need a high performance DB (or the scale were this is a problem) you should probably use postgres anyways?

2. The pure Go library will be somewhat slower

but for the same reasons as above, I dont think it matters over the other practical gains... Benchmarks: https://github.com/glebarez/go-sqlite/tree/master/benchmark

I'll try to investigate the single connection a bit, might be something I did, or it might not matter.

@juanfont @cure thoughts on the benefits vs drawbacks?

edit: One other "risk" is that the library is not official, it is mentioned on GORMs website, but there could be a risk of it becoming unmaintained, on the other hand, it might become official.

[cure]

I don't think that in principle, a single concurrent connection is going to be a problem for our use case. Any delays because of this are unlikely to be significant for small-ish sites. And if it becomes a problem, the site can always switch to PostgreSQL.

Maybe we could somehow measure connection contention and expose it as a metric? But that should probably be a separate story, and it may not be worth the effort.

I'm not concerned about the library being official or not. If it becomes unmaintained later, we can deal with that then.

Getting rid of CGO is really nice and will speed up builds etc!

[kradalby]

Yes I agree, I am happy to just get it in and test it. As it passes the tests without any noticeable change in teat time.

I'm making this ready, let me know if your happy @juanfont @cure .