Gradual shift from Opaleye?

[chpatrick]

Hi!

This package looks really nice and I would love to try it. The problem is that we have quite a lot of code that currently uses Opaleye. Do you have any advice for how to replace some of it with rel8, perhaps only the schemas at first, while keeping our existing Opaleye queries?

[abigailalice]

Just another library user, but I'm not sure if there's a good way to do that, at least how you're asking. If you were working from a fork of Rel8 you could look at modules like Rel8.Expr.Opaleye and Rel8.Query.Opaleye, which have functions for converting between the two. So you could potentially use them overtop a call to each someTable to convert the Query to a Select, and the Expr as to Field_ n as, provided the table schemas don't use of Rel8's more abstracted sum-typeish types (but you wouldn't yet be).

But caveat emptor. My understanding of those functions is strictly limited to seeing that their types are suggestive. So you could end up spending a bunch of time and then find out they're internal for a reason. And honestly, I'm not even sure that would be as trivial a change as it sounds, because even if they do what they're types suggest, it would also effect all your inserts and deletes, which would then need to be modified too, and I'm not sure there's a way to do that, without hacking on even more internals.

If not, you'd also have to then change to rel8's insert/delete mechanism, which means changing to hasql, which means if you've got your sql under some sort of transaction now you're trying to have hasql-transactions coexisting with postgresql-simple, though I don't think there's going to be an easy way to do that either, and it just looks like every problem begins compounding on each other.

By the end you could have done made as big a change as you were trying to avoid, just with no guarantee that the thing you hacked together will even work to begin with. I had to migrate my own code base, and ended up doing it monolithically, but if that wasn't an option I think just having table definitions duplicated for a time, and treating each transaction as your smallest unit of change would be the safer option.