Meeting 2024‐03‐22

Workday sponsorship

They are sponsoring us to work on composite foreign keys. Waiting for confirmation before we start working on it.

Do we want to move dialect-specific data types to dialect packages
- If the DataType is supported by more than one dialect, it can go in core, otherwise it goes in dialect packages
Dialects could ensure that the core version matches the dialect version (so ideally they should be exactly equal)
Splitting tests is something we can look into later
Dialect toolkit
- Basically a public API that exposes everything that's needed to create a new dialect for third-parties
- Won't be released officially in v7. We'll work on it slowly but not a high priority.
We want to move iBMI and Snowflake to a community org because we have no way to integration test yet
- Note: Rik managed to get a connection to an iBMI machine & log in. Worth looking into
- Sadly we can't run more than smoke tests, as the machine is a community one and is very slow
- Tried to reach out to snowflake but no answer
  - Let's try to reach out again through https://snowflake.research.net/r/dev-open-source

Once we are ready to release v7, we need to reach out to the oracle team to update their v6 implementation
- They were pausing development while working on their updated connector
- Or maybe once the dialects are split, depends on our release strategy for v7

PR is pretty much done. It was split in two PRs (one without transactions and one that adds transactions).
- https://github.com/sequelize/sequelize/pull/16394
Next step: Review it
They expressed interest in sponsoring us
They had a lot of merge conflicts due to how many major refactors we've done, such as moving to prettier, extracting utils to their own folders, and likely soon, extracting dialects

Two blockers remain: CLI (in progress) and extracting dialects (in progress)
- After the dialect extraction, we will go into beta
- We would like to merge @lohart13's migrating-to-typescript PRs before the stable release
We will continue to support v6 for 6 months after releasing v7
We are starting the CLI from scratch using oclif, TypeScript-first, ESM, etc
sequelize-auto will also be moved inside of the CLI
We want to add migration generation to the CLI (one that compares local models to the database tables and generates the SQL to update it)
For future major changes, what we want to do is:
- Implement anything that requires structural changes now, such as extract dialects
- Improvements to existing features that require breaking changes will be done by copying the method into one prefixed with UNSTABLE_. Once it's time to do a new major release (ideally once a year, in may-june), remove the prefix, and move the old implementation to the LEGACY_ prefix (for one major release), so people have an easier time updating, and we're not stuck working on v8 for 2 years and we can continue working on them in the v7 release
Do we want to do https://github.com/sequelize/sequelize/pull/17124 in v7?
- Not a blocker so if it's ready before the stable release, good. If it's not, it will use the UNSTABLE_ prefix
Aiming for june for the beta release, but we had the same conversation two years ago. It's very difficult to plan a project you do on your free time

Issues we talked about during this meeting (notes in issues)