Issue: Cannot convert RELATION to column type
Hello, I am getting the issue while upgrading from v1.3.1 to v1.4.12.
27 Replies
Hey @Jay Patel could you please share more context ? When it this occurring ?
While upgrading from version 1.3.1 to 1.4.12, I first ran
yarn database:migrate:prod, which completed successfully. However, when I executed yarn command:prod upgrade, I encountered an issue.Are you guys configuring the
APP_VERSION env var accordingly when building your twenty custom image ?Yes, I used APP_VERSION=1.4.12 while upgrading.
Could you please share the whole line ? do you have the corresponding service name initiating the log ?
Here, I have attached a complete log file of the upgrade command. Please let me know if you require any further information.
Hey @prastoin, any updates on the above issue?
I have a debug function called updateFieldMigration, and I found that the above field might be causing the issue. However, I’m not sure how this happened.
Hey @Jay Patel do you have a custom field named view ?
Ah
Nope, we don't have a custom field named view.
Here is our "view" related fields metadata list.
@prastoin I compared the standardId for the issue field: "20202020-5a93-4fa9-acce-e73481a0bbdf".
In v1.3.1: 20202020-5a93-4fa9-acce-e73481a0bbdf appears as a view field with type RELATION.
In v1.4.12: the same ID appears as a viewId field with type UUID.
I’m not sure why this discrepancy occurred, as we haven’t made any direct database updates.
Hey @prastoin, did you find something? Due to the we are blocked for the v1.4 upgrade.
It would be helpful to us if you found anything.
@Guillaume @ɃØĦɆᵾS Could you please help here?
It is different from the favorite workspace entity file from v1.3 to v1.4. And this standard ID field is causing the issue in the workspace:sync-metadata command.
Sorry but I don't know how to help when it comes to problems with upgrades
It should not be mutating the old but the new view definition
Yes, but these changes are in v1.4, so we’ve set APP_VERSION=1.4.12. The upgrade command will detect version changes based on that and run the v1.4 commands. However, the new definition change command is specified only in the v1.5 commands.
I don't think that will be an issue, we might have been facing an edge we patched in 1.5
Let's say we are currently on v1.3 and gradually upgrading up to v1.6 with DISABLE_DB_MIGRATIONS=false (so auto migrations are enabled), what should the APP_VERSION value be set to for each corresponding codebase version?
For example, for the v1.4.12 tag, we set APP_VERSION=1.4.12. How should this be handled for the versions up to v1.6?
Because I’m getting a bit confused with the tag names (v1.4.12, etc.), APP_VERSION, and the specific upgrade commands related to each version.
Let's say we are currently on v1.3 and gradually upgrading up to v1.6 with DISABLE_DB_MIGRATIONS=false (so auto migrations are enabled),👍
what should the APP_VERSION value be set to for each corresponding codebase version?If you checkoug twenty vx.y.z you should set the app version to
x.y.z
I would recommend checking out the latest published patch version of it minor version ( that's not because a tag exists on github that it has been deployed on docker hub, it was created to fit a cloud production need rather than compatible for self hosted )We are also self-hosters and run Twenty + our own code together, so we need to rely on the GitHub codebase only (not Docker Hub). In that case, how should we pick the correct codebase/tag from GitHub for a specific version (e.g., v1.4.x, v1.5.x, v1.6.x) to ensure we’re aligned with the right APP_VERSION and upgrade path?
Please checkout tag also available on dockerhub to avoid any issue
So, as of now, should we proceed with the manual upgrade from v1.3.1 to v1.4.12?
Currently, I have merged the v1.4.12 tag, and for the migration, I plan to run the manual upgrade commands as follows with APP_VERSION=1.4.12:
yarn database:migrate:prod
yarn command:prod migrate:1-5:remove-favorite-view-relation
yarn command:prod upgrade:1-5:add-positions-to-workflow-versions-and-workflow-runs
yarn command:prod migrate:views-to-core
yarn command:prod workspace:sync-metadata
After running these, my production environment should be upgraded to v1.4, right?
You should not have to run any commands, if you guys do not disable auto migrations and do consume the entrypoint.sh as docker file command the upgrade command will be run automatically
You should not have to run 1.5 commands on 1.4
After running these, my production environment should be upgraded to v1.4, right?No only the upgrade command mutate the workspace version in db If you face an issue while being in 1.4 upgrading to 1.5 should fix the problem if it's related to a 1.5 command not being run
We are using entrypoint.sh, which checks the APP_VERSION value and runs the corresponding upgrade commands.
I want to upgrade to v1.4.12, so I set APP_VERSION=1.4.12. Running:
yarn command:prod upgrade
should execute the commands from the const command_1.4 based on my APP_VERSION.
However, when merging the v1.4.1 tag code, there are no upgrade commands defined in const command_140; the necessary commands are only available in const command_150.
Upgrade command will only run if you have a gap of a one minor version between workspace version and APP_VERSION
It's not required to upgrade to latest patch of the currently installed version
If a patch contains a command it would be added in the next minor release anw
By considering the issue I’m facing, I’m running into a problem while upgrading from v1.3.1 → v1.4.12. How should I proceed with the upgrade — do I need to go through any intermediate minor version upgrades?
Could you please let me know which minor version I should take for the intermediate migration?