update go-sqlite3

[wkloucek]

Description

This PR would remove the annoying / confusing SQLite compile warning upon compiling oCIS.

go build ./cmd/ocis
# github.com/mattn/go-sqlite3
sqlite3-binding.c: In function ‘sqlite3SelectNew’:
sqlite3-binding.c:128049:10: warning: function may return address of local variable [-Wreturn-local-addr]
128049 |   return pNew;
       |          ^~~~
sqlite3-binding.c:128009:10: note: declared here
128009 |   Select standin;
       |          ^~~~~~~

Background

github.com/mattn/go-sqlite3 has some weird versions. The highest version number is v2.0.5, but the newest version is v1.14.7. This leads to a very chaotic situation. Even https://github.com/gobuffalo/pop/blob/master/go.mod does use a replace directive...

Considerations

• overriding a dependency is never nice
• create PRs at the libraries using the old version of the sqlite lib
• the compile time warning is not too bad

I wouldn't even know where to start in our upstream libs to update go-sqlite. go mod why github.com/mattn/go-sqlite3 for oCIS gives us:

# github.com/mattn/go-sqlite3
github.com/owncloud/ocis/ocis/pkg/command
github.com/owncloud/ocis/storage/pkg/command
github.com/cs3org/reva/cmd/revad/runtime
github.com/cs3org/reva/pkg/storage/fs/loader
github.com/cs3org/reva/pkg/storage/fs/local
github.com/cs3org/reva/pkg/storage/utils/localfs
github.com/mattn/go-sqlite3

So this is coming from REVA. go mod why gives us:

go mod why github.com/mattn/go-sqlite3
# github.com/mattn/go-sqlite3
github.com/cs3org/reva/pkg/storage/utils/localfs
github.com/mattn/go-sqlite3

Which is only the half truth (direct deps) and go mod graph | grep sqlite shows the full picture:

github.com/cs3org/reva github.com/mattn/go-sqlite3@v2.0.3+incompatible
github.com/gobuffalo/pop/v5@v5.3.1 github.com/mattn/go-sqlite3@v2.0.3+incompatible
github.com/jmoiron/sqlx@v1.2.0 github.com/mattn/go-sqlite3@v1.9.0
github.com/gobuffalo/nulls@v0.2.0 github.com/mattn/go-sqlite3@v2.0.3+incompatible
github.com/gobuffalo/nulls@v0.3.0 github.com/mattn/go-sqlite3@v2.0.3+incompatible
github.com/luna-duclos/instrumentedsql@v1.1.2 github.com/mattn/go-sqlite3@v1.11.0
github.com/gobuffalo/pop/v5@v5.0.11 github.com/mattn/go-sqlite3@v2.0.3+incompatible
github.com/ory/x@v0.0.84 github.com/mattn/go-sqlite3@v1.10.0
github.com/gobuffalo/fizz@v1.0.12 github.com/mattn/go-sqlite3@v1.9.0

You will notice github.com/gobuffalo/pop again which itself uses a replace directive...

My first attempt was a go get github.com/mattn/go-sqlite3@v1.14.7 in REVA, but that leads to a downgrade of github.com/ory/fosite, which lacks some interfaces needed by REVA.
If you check why fosite needs go-sqlite3:

go mod graph | grep sqlite
github.com/gobuffalo/pop/v5@v5.3.1 github.com/mattn/go-sqlite3@v2.0.3+incompatible
github.com/jmoiron/sqlx@v1.2.0 github.com/mattn/go-sqlite3@v1.9.0
github.com/gobuffalo/nulls@v0.2.0 github.com/mattn/go-sqlite3@v2.0.3+incompatible
github.com/gobuffalo/nulls@v0.3.0 github.com/mattn/go-sqlite3@v2.0.3+incompatible
github.com/luna-duclos/instrumentedsql@v1.1.2 github.com/mattn/go-sqlite3@v1.11.0
github.com/gobuffalo/pop/v5@v5.0.11 github.com/mattn/go-sqlite3@v2.0.3+incompatible
github.com/ory/x@v0.0.84 github.com/mattn/go-sqlite3@v1.10.0
github.com/gobuffalo/fizz@v1.0.12 github.com/mattn/go-sqlite3@v1.9.0

You will again notice github.com/gobuffalo/pop ....

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[wkloucek]

@refs what do you think about this? should we just stick the the compile time warning or should we go the replace step? I don't think that we can solve this on some upstream lib since it is a huuuge mess.

[butonic]

@labkode @ishank011 I think we should remove the ory fosite based openidprovider in reva. It really was a temporary hack until a proper idp was available.

[wkloucek]

@labkode @ishank011 I think we should remove the ory fosite based openidprovider in reva. It really was a temporary hack until a proper idp was available.

That would also work: cs3org/reva#1860

[refs]

I think that'd be the closest solution. I'm sure someone®️ has a replace on an obscure branch just like etcd had, but that's an insidious option. I'd +1 @butonic proposal

[wkloucek]

was solved in reva