Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

Let’s start off with a quick message from your favorite friendly neighbor named “Ana Lyst”:

1
2
3
4
5
6
7
8
9
10
11

Dear low-code friend, (owh boy!)

Last year we (or better you!) implemented a great inherited 
case management system. "The business" (not me!) wants to 
rename one of the specialized subtype entities with 
a "smarter" name. The old name makes the knowledge workers 
nervous and "unpredictable" in their choices.
As the platform is highly configurable it would be a "quicky"...right? :)

Let me know the impact, so we (!?) can inform the business about it.
BR, Ana

WHAT? 🤔🤣😒🙃😮

Let get right into it…

After a good night sleep, you (with the team) decide to first sandbox this request to see what will happen (especially with the current entity instances)…Well, this post is the result of the try-out! Indeed…How hard can it be?

To mimic the current situation a little, we rebuild the current solution in a quick and small setup. This means a new workspace, one generic project, and a second specialized project. The generic project has a building block enriched ‘Case’ entity and the specialized project has a subtyped ‘SpaceCase’ entity (no wonder your knowledge workers get stressed out 🤣). Dress up the ‘CaseSpace’ to be a bit more manly. See the result:

Notes:

• Don’t worry about nice forms/layouts. We do create new instances in runtime, but only to check the outcome of our actions below.
• If you don’t have a clue how to create subtypes/project; Have a search.
• You can drag & drop entities to other project…In case you wondered after the subtyping action!

It’s time for a first publication into runtime…You’ll end up with two lists where you quickly create a couple of instances for both.

If you ask the valid question why both entity instances mix-up in the ‘Cases’ list!? That’s because of the inheritance for the subtyping we did.

Let also have a look in the database (PostgreSQL in my case) before we start renaming things:

You can use a tool like HeidiSQL to make the above screenshot possible.

You see that inheritance puts our ‘SpaceCase’ entity in the same table (read about it here); Trust me that the case_is_special property is available at the end (outside the screenshot)! 😇

Let’s set the expectations before we start the rename action. Our subtype entity “lives” in the same table, so this would not impact anything is my assumption. We’ll also rename the parent ‘Case’ entity, but as read before this should also work as expected. So, you’re telling me that everything gets along!? Well, indeed…Let’s see…

We’ll also keep track on the existing entity instances and have a double-check in runtime if they are untouched as well…Incredibly important in a production organization!

Be aware that I do this post in a sandbox environment; Always make sure to make a backup your database to #CYA (Cover Your Ass!)

Rename time

First, we’ll rename our space_case entity; Do a right-click and rename the entity to case_special. Open the entity and update the display name of the entity to ‘Case special’. I also update the lst_space_case to lst_cases_special with a better label in runtime.

Next is a deployment of the renamed entity and have a look in runtime:

I also added the ‘EntityType’ property of the identity to the lst_cases to see the difference on the new name!

A quick double-check in the database tells me it’s still the same with also the same entity TypeID as the “discriminator id”…Well, great!

…

The next rename is our case entity; Again, a right-click and a rename to case_generic (I know…case was the better choice here!). Give it also the display name Case generic and leave the rest as is. Now do a deployment into runtime and have a check:

It just works…Data itself is still intact! 🤠

From a database perspective, I do see a change in the name of the entity table name…(NICE!):

…

A final question to answer; How save are we on the relation building block part as I almost forgot that part; Not on purpose, but just not thought of until this moment. To try this out, I create a config entity like this:

From the case_generic entity, I’ll create a new ‘toOne’ relation BB to the ‘Config’ entity with the name to_one_config. On the ‘Create’ form, I’ll make sure to add the relation to make it a solid connection into a container component:

Do a publication, and update the ‘Case generic’ instance with a new instance of the ‘Config’ entity:

From a database perspective, I see two changes:

1. The ‘case_generic’ table gets an additional to_one_config_id column
2. We’ll get a new ‘config’ table for our organization

So, my assumption again; A rename of the entity back to case will not impact this relation part as they are two independent tables linked via the new column! Trust me ( 😇 ), I just finished the task, and it’s exactly executed as expected…Well, that’s an excellent job! AND for your convenience, I also rename the config entity to something else, and it works solidly as well afterward.

That’s also a job’s done from my side…

…

‼ Ohwwww; Before I forget…A last comment. Never, ever, only change “the label” for convenience customer happiness…It will (100% sure) hit the wall in the future repeatedly! You don’t want to know what I see passing by in the battle field at customer projects.

That’s a predicted “DONE” this time; Once, in an older project (with an older version of the platform) a saw this going wrong dramatically with managers getting nervous what would be the next step; Not anymore! BUT, if this is working well, why is there no option to rename the name of a property for your solution? Isn’t this strange? Or is renaming a property a much harder task to accomplish as it is reused in several types of documents as well…Give me a comment when you’re close at this discussion. In the meantime, you can do a “smart” remove (which includes a search in the sources on references), create a new property, and reconstruct the damage! I leave it for now; Have a great renaming weekend and I see you next week, in a new post. Cheers!

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?