[81reap]

Issue #1056 moves SQLPage from sqlx-oldapi to mainline sqlx. To let us test that on our own databases before customers can reach it, ODBC connections can now run through sqlx 0.9 and the sqlx-odbc driver gated behind a feature flag.

1. Build with the unstable-sqlx-next Cargo feature. Releases and Docker images do not enable it.
2. Set SQLPAGE_UNSTABLE_SQLX_NEXT=true, or unstable_sqlx_next in the configuration file. The option only exists in builds with the feature.

Alpha (1 & 2) -> Beta (2) -> Prod (neither, its always on)

SQLPage does not route some features through the new driver yet, I would like to take some time to think through the interfaces.

Refs #1056

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

[lovasoa]

very good to take the time to test first. But do we need all this new setup? Could we just operate a git branch with the new sqlx ? and just merge main into that branch from time to time? agents are good at fixing conflicts, and they should be localized (or at least, they should be, if we are depending on sqlx-oldapi in unexpected places, we should refactor on main first)

[81reap]

we could do it the feature branch way, but I think that would only affect the alpha part of the dailup, no?

1. Alpha :: You have to recompile sqlx and set an env flag in order to be able to use the feature. We stay on this until we no longer need to be on unstable_sqlx_next and can get on an offical version. This could be on a seperate branch.
2. Beta :: We compile the feature by default but users can opt in via a env flag. This lets us solicit feedback from users on issues relating to sqlx. This cannot be on a seperate branch as we need to deploy a published version for users to upgrade to and use.
3. Gamma :: Technically at $job Gamma is UAT, but I don't see much diff between gamma and beta for this dailup.
4. Prod :: When we feel comfortable that there are no more issues, we cut over by deleting sqlx-oldapi and promoting the feature flag to be on by default.

To avoid suprises it made sense to me to also validate how end users will cutover to this new feature. This is how we do large cutovers and migrations at by $job and imo it scales pretty well as a solution. Happy to know your throughts tho, we can pivoit to a middle ground or a safer dail up SoP.

[lovasoa]

I think it's ok to just ask beta testers to download separate binaries. sqlpage probably has way fewer users than $job, and sqlpage users are more attached to it, and I think we'll just ask nicely to long time users to download the prerelease binaries, and they will do it. We keep the code clean on our side, and don't maintain a dynamic database backend switching system. Also, we don't ship binaries that are larger than they need to be.

[81reap]

with prerelease binaries, wouldn't we have to keep cherry picking commits to rebase the sqlx change under until the feature is ready to be released with a version?

1. alpha :: separate branch
2. beta/gamma :: changes are floating on the tip of unreleased changes. if we need more time to work on the changes it blocks releasing new versions of SQLPage unless we take extra steps
3. prod :: deprecate sqlx-oldapi

the $job workflow is more so to be able to dial up new features without blocking the pipeline. unless there is a way to release from a seperate branch than mainline?

[lovasoa]

We wont cherry pick commits, we will just merge main into the branch from time to time. I do not expect us to need to do that more than a few times, given the speed at which main moves. Nothing blocks new releases, on the contrary: we don't affect the actual binary used by users at all. If we decide not to commit to the change in the end, abandoning it is free.

Let's focus our efforts where they are productive: not the ceremony:

• Adding better sqlserver and duckdb tests to main: useful, no blocker
• porting the code to sqlx: the blockers are making the sqlx driver crates bullet proof. Don't hesitate to move fast and break things in them.
  • https://github.com/lovasoa/sqlx-odbc
  • https://github.com/lovasoa/sqlx-sqlserver/

Once that is done, I'll be much more confident in the change, and we'll do it quickly.