Forum Academy Marketplace Showcase Pricing Features

Deployment issues re changes in schema

Question
#1

I wonder how does Bubble handle the case when I have a live version with its app logic, workflow and data and then I upgrade another dev environment into production (live).
Now there might be some schema changes (to datatypes and fields). How does it map into the existing production data that resides within the current production environment?
What errors prevent from upgrading because of data types inconsistency or data integrity and what changes to the data schema can pass successfully into the new production environment?

Regards, Alon

#2

Anyone?

#3

Long story short, any changes made within the editor are automatically transferred across without issues arising. This is because there are hidden IDs which Bubble uses to match fields together, even if you rename them.

Bubble prevents you from editing a field’s type after creation (for example, from number to text) and this significantly reduces the number of possible issues.

If you find that you’ve set a number field but you actually need it to be a text field, you can then create a new text field and use a workflow to copy the data across. You’ll do this first on dev version and if you’re happy, you’ll also need to perform this on live version too.

If you remove fields or data types, these are easily reflected in live environment after deploying.

@emdr.il.dev1 Is there a specific use case you’re concerned about?

#4

Thank you very much. I think I should try and parametrize as much as possible constants and set them within OptionSets. Thus when deploying from dev into prod, those parameters will not be influenced. For instance, I am interfacing a local STRIPE - like payment gateway who presents two different instances for testing and production. Thus I might set it parametrically so always to be calling upon the relevant gateway as I deploy versions.

I guess the data within OptionSets will not be deployed between deployments.

@emdr.il.dev1 is another development account we use. :slight_smile:

Thank you very much!

#5

Quite the contrary. All option sets - including data - are updated with each deployment.

Don’t know if it helps, but there’s the Isn’t live version expression which enables you to create conditional logic based on dev or live.

-Steve

#6

You are right! My mistake.
So I have defined an optionset with two values, for dev and prod. Added a page level custom state which is updated upon the page loaded event depending on the “Isn’t live” value.
Easy and no reason to make a database call just for that.
Thanks!

1 Like