Make import of SqlBackend fields explicit

[mjgpy3]

Per this stackage issue: commercialhaskell/stackage#6032

[z0isch]

Hmm- I guess Database.Persist.Sql stopped exporting these fields? I wonder why?

[mjgpy3]

@z0isch good question! Seems to have happened in this PR: yesodweb/persistent#1225

Maybe this is indicating that we're not building this totally correctly...

[mjgpy3]

I'll dig in a little more before merging this.

[z0isch]

@z0isch good question! Seems to have happened in this PR: yesodweb/persistent#1225

Maybe this is indicating that we're not building this totally correctly...

Yeah it looks like we should maybe switch to the mkSqlBackend function?

[pbrisbin]

Just a headsup that getting green CI doesn't always indicate you've fixed something like this. In most projects, we run CI with the latest LTS resolver. Sometimes we also build with older resolvers. We rarely have a CI job with nightly and we never build with latest Hackage.

That means that if we have a lax upper bound (which we're moving to) we could see breakage with a newer nightly/hackage dependency that won't reproduce on CI.

I'm stilling thinking of the best way to address that fact, for now it's kind of just a "be advised" situation like this. Making a nightly CI job part of our prescribed suites could be good enough (latest Hackage feels like overkill).

[mjgpy3]

@z0isch I think that that constructor function may not be too great here. Since our pattern to modify an existing backend creating a new one feels tedious and requires me to use those internal fields anyways (to map all existing, required fields that we don't modify over -- looks like 10 fields).

@pbrisbin I tried constraining my local build to take a fresher persistent (persistent >= 2.13.0.0) and this built. Does that serve as an adequate test?

[pbrisbin]

@mjgpy3 I'd imagine that works. I would've probably just built with --resolver nightly since that's quicker and should reproduce what the Stackage curators hit.