kitchen_sync
kitchen_sync copied to clipboard
MySQL -> Postgres | ENUM Columns
Is it possible to add some kind of laravel compatibility flag to parse ENUM columns in MySQL as varchar for Postgres to avoid having to CREATE TYPE for each enum that lives in the source db? This issue is particularly scoped to Laravel, which creates ENUM columns as varchar(255) with constraints...for some reason. As laravel auto-generates schemas for both db engines from a migrations file, simply inserting the existing enum value from the source table into the target table if the table schema already exists would be fantastic
Hmm interesting idea. Maybe I should just make it create the types with arbitrary names for you?
Or are you specifically trying to match the Laravel-created schema from mysql with a Laravel-created schema with postgresql?
The latter proposition is the actual situation in my case. The former is probably the schematically "correct" way to approach the problem, however it would only fix the migration issue and any new enums created via migrations in (Laravel) code would result in being mismatched types. I imagine most of the use cases for mysql -> postgres will be Laravel users, as we can change the db driver with a single line of code, but it kind of doesnt make sense for you create workarounds for a single framework...its a tough one lol. The automatically created types with some kind of report on the types created (for reference / changing later) would probably help the most people in general, the ability to cast enums to basic varchar when doing mysql->postgres would probably help only Laravel devs.
In your case the entire matching schema is already loaded up at the 'to' end right? And it would actually work if KS ignored its own opinion about the column type and tried to sync into it anyway?
Correct, I have the schema pre-generated in the target db currently, which is how the error came about and caused me to compare the schemas more closely. Its hard to say if its the only issue and will work 100%, but I did manually "CREATE TYPE" for a few enum columns on the target postgres DB and did not get any additional errors on tables where I added the arbitrary ENUM type, it just errored out on the next enum type issue in another table, so it looks very promising if this issue can be worked around. Perhaps your idea to generate arbitrary names would be a great first step - it would work as a debug step to eliminate one set of issues for my laravel migration for me to debug without manually adding types myself (we have over 100 enums), and would provide an outright solution for the issue for non-laravel users as well. If the laravel migration succeeds with the arbitrary enum type creation, it means that there are no issues beyond the ENUM -> Varchar column type discrepancy and adding a --laravel
flag or something to cast ENUM in Mysql to Varchar in Postgres would hopefully solve all (at least all of mine) laravel migration issues.