Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

backend: queue v2 migration steps #5029

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from
Draft

backend: queue v2 migration steps #5029

wants to merge 7 commits into from

Conversation

uael
Copy link
Collaborator

@uael uael commented Jan 8, 2025

No description provided.

Copy link

cloudflare-workers-and-pages bot commented Jan 8, 2025

Deploying windmill with  Cloudflare Pages  Cloudflare Pages

Latest commit: 8b1c81c
Status: ✅  Deploy successful!
Preview URL: https://b2803a51.windmill.pages.dev
Branch Preview URL: https://uael-queue-v2.windmill.pages.dev

View logs

…ve `v2_job_queue` row exists for foreign keys
@uael
Copy link
Collaborator Author

uael commented Jan 8, 2025

Because of how views works (not null constraints not reflected), this migrations make sqlx queries impossible to compile (e.g. Uuid/Option), but all the already running code remain 100% compatible, while using the new schema. The caveats are pretty small and are discarded when all running server(s)/workers(s) are up to date:

  • Some columns and their data are duplicated (e.g. __flow_status in v2_job_queue and flow_status in v2_job_flow_runtime)
  • Each insert/update on queue are reflected on v2_* tables using triggers -> overhead.
  • Each insert on completed_job are reflected on v2_* tables using triggers -> overhead.
    I will add a custom migration step which once everything is up to date (i.e. all processes run under the new version), will drop the triggers, the compatibility views, and the old columns.
    After this migration step, no more overhead or duplicated and the migration is complete.

To resume:

  • Transparant migration v1 -> v2
  • Missing triggers for v2 -> v1 compatibility
  • Missing indexes, policies and triggers
  • Update code to use updated tables and not the compatibility views
  • Add custom migration step to finish the migration when all workers are up to date

@uael
Copy link
Collaborator Author

uael commented Jan 8, 2025

Another option is to temporarily change all checked queries that does not compile because of views to unchecked query in order to merge this, which allow to discover if the transparent migration works correctly, and then proceed with next steps:

This PR:

  • Transparant migration v1 -> v2
  • Missing triggers for v2 -> v1 compatibility
  • Missing indexes, policies and triggers
  • Tmp checked queries to unchecked

Next PR(s):

  • Update code to use updated tables and not the compatibility views
  • Re-check queries
  • Add custom migration step to finish the migration when all workers are up to date

RETURNS TRIGGER AS $$
BEGIN
-- `v2_job`: Only `args` are updated
IF NEW.__args IS DISTINCT FROM OLD.__args THEN
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Text cast

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant