Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
In this post we’ll dive a bit deeper when things need to be updated on the property building block level.
The use-case: Let’s say you have a nice solution available in runtime where the end-users also created a lot of instances of all the crafted entities. There will be a time when the ‘Analyst guy’ of your project decides that a property length needs to be updated!…What?…Yes, and updated in a decreased length!…Well, the big and great question is if it’s possible and what happens with all the values that are already created for that property!?
Let’s find it out in this post…
Let get right into it…
As always (and maybe you already have it up and running!?)…spin up your machine and login to your most favorite organization and open you workspace with corresponding project.
We’ll start with a simple ‘project’ entity that has a property ‘name’ of type ‘Text’ with a field length of (default) 64. We also add all the default building blocks, so we can test this entity in runtime; So, a ‘Default’ and ‘Create’ form (and maybe a layout!?) and a default ‘All projects’ list.
Just create some instances in runtime, so you get a result like this:
Yes, that test000…2 is of length 64!
Maybe interesting to also have a view on database level?…For this we have the tool HeidiSQL. After installation, you can start up the tool to make a connection to (in our case) the PostgreSQL database on our VM:
Open the ‘public’ domain of the database and open the table (in my case ‘o2appworkstipsappworksproject’) for an overview of columns. There we also see our ‘name’ property of type ‘VARCHAR’ and a length of 64…As expected!
And after the execution of this query you get a nice overview that we can double check when we start changing things. Especially that ‘name’ column will be interesting to watch!
Ready for some hacking? 💪
Back to design-time and opening our ‘project’ entity…
Let’s increase that field length to 128!?
Save, publish, and test in runtime!
Can we still see/use all our project instances?…Yes we can…Lucky us!
And can we add extra values to the ‘test000…2’ instance?…For sure, we can!
What happened in the database?…Well, after a disconnection and reconnect we see what we expected!…Size 128!
So far…so good…Now for the next section…Do you feel the adrenaline! 😅
Now update that field back to the original length of 64!!…Yeah…Don’t blame me…Blame the ‘Analyst guy’!
Save, publish, and refresh in runtime!
There you have it…
As expected I would say…
This also means our ‘long’ value is still available in the database!…Let’s check it out…
Well…our column ‘name’ is still size 128!?
And that query for the results?…Well, that provides us with the last saved value…Lucky again for us as the data is still intact!
Ok…Update that value in the database and bring it back to a size 64…Is it working again in runtime?…Ohww yeah…It’s working again without an error in runtime!
Can we update the value in runtime and make it longer again…Well, not at all as we made it 64 and that is checked by the platform field validation! So your typing will stop when you reach size 64.
Now we’ve created some inconsistency in the database where the database is telling us the ‘name’ column can have size 128, but runtime can only handle size 64…You get the point…right?
You can solve this on database level where we need to update that name column back to size 64…also here…You can only update this when the values in the column don’t exceed that size you have in mind…
Well, looks like a “DONE” to me and good to see that our AppWorks platform is solid enough to handle a change like this. Also, the decreasing of the ‘Text’ property size is working fine. We tried all kinds of updates, and we see that the data in the database will never be manipulated. That is also a solid solution as we leave this value change at our customer who needs to decide what needs to happen!
Have a nice week-end, and I see you in the next post…