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

Suggestion/discussion: Mysql-MariaDB Flavor #1781

Open
jeremydenoun opened this issue Aug 26, 2021 · 0 comments
Open

Suggestion/discussion: Mysql-MariaDB Flavor #1781

jeremydenoun opened this issue Aug 26, 2021 · 0 comments
Labels

Comments

@jeremydenoun
Copy link
Contributor

Hi,

I am happy to see that the project is coming back to life, in particular because I have launched a project where I'd like update
my stack and especially projects where I use Propel2.

During my updates, I must consider switch to other mysql flavor previously I use Oracle MySQL 5.6/5.7, in past I switch to Percona 5.7/8.0 without any issue (there target is to follow at maximum MySQL behavior so this is often painless) but I try to switch to MariaDB and I see they are more SQL dialect respectful but can differ than MySQL about some return.

This impact directly propel in "Database Diff Computing" because Column Reverse can differ (and potentially make loop).

I'd like your opinion about the right way to handle flavor in Reverse/Platform/Compare workflow, an example if you define a timestamp column with defaultExpr look like CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, mysql/percona reverse will look like CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP (so match) but MariaDB return CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP() (so doesn't match)

What is the most elegant fix to support multiple (especially in behavior) ?

  • consider alternate defaultExpr / defaultValue (in Column definition) that can be used in fallback in Diff Class (and can be directly define in behavior)
  • consider switch/case with normalization for detected case in MySQL Reverse Class (but should be mysql specific)
  • consider convert/analysis value directly in DiffClass to have a more efficient similar column detection (but should be global)

From my side I made branch to match my flavor, but I think a way to handle this properly (and maybe for all kind of use case can happened) can have benefit for all

Thanks for your reply

@jeremydenoun jeremydenoun changed the title Mysql-MariaDB Flavor Suggestion/discussion: Mysql-MariaDB Flavor Aug 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants