Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
Sometimes you have those lunch walks with a colleague where you just free your mind in a creative manner by brainstorming on interesting scenarios…I always immediately right them down as I know that after the brainstorming it’s quickly forgotten, but most of the time highly valuable to share the final thoughts with others after a quick R&D from my side!
So, this week (and next week) two outcomes of a rather quick lunch walk, but that’s what you get when the tensions are high…A little stress (not too much) brings just that little extra in your head to collaborate about; For this week a dive into the database as we were just asking a valid question: What on earth is created at database level when you customize (or subtype) an “Identity” entity? Why asking this question? Well, we saw already interesting things during our subtyping post! With this mindset we “think” that subtyping will save the entity in the same table (as already concluded in the related post, but could the identity package behave differently?) AND we “think” that customizing will save it in a new table (as the name of the entity should equal the identity entity, or could it be a reason to save it in the same table!?)
We raised the bar…We asked valid questions, time for action!
Let get right into it…
This post will be an easy one, but it will provide great insights on what is happening in the backend database of our beloved AppWorks platform. So, boot up your VM, make sure all is running fine and dive into your favorite workspace with related project (or create a new one if needed…A task on your own).
Next step is to also have a connection open to the database of AWP; In my case this is a PostgreSQL database which I can connect to over the tool HeidiSQL.
This is my view on current things with a basic project structure and the option to show the platform packages:
Diving further down the identity package structure it’s possible to do the appropriate actions for this post:
From a database perspective you’ll find (for each organization!) a set of identity tables where the above ‘Language’ entity saves itself (for my organizationId 2) in table o2opentextentityidentitycomponentslanguage.
You can do a double-check in runtime creating a new language instance from the identity node in the ‘Home page’ layout:
…
In the database you’ll find an entry like this:
Time to dive deeper…
Create a subtype
Notes upfront on “subtyping”:
- You create a “specialized” entity for your specific requirements (incl. functionality from the parent!)
- Name should be different from original name (as it’s a specialization)
- Inheritance of building blocks (not the lists!) happens from the parent for you to further change them via the replacement action
- You can add new building blocks
- The ‘abstract’ and ‘re-usability’ options are reconfigurable
Let’s create a new subtype of the identity ‘Language’ entity. You’ll get a new screen to set the properties with a valid name language_special. We’ll also add a new Boolean property lang_is_special (default with TRUE), exposed in the replaced ‘Create’ form, and in a new list lst_special_languages:
Don’t forget to also replace the ‘Security’ BB to set the correct permissions for the new property and this list!
Save the new entity (in the entities folder of the project), and do a first deployment to conclude you’ll get an error:
Nothing fancy…That’s a simple right-click on the entity in your project and call the action ‘Reconstruct Translations’:
Do a republish, and you’ll be fine to move into runtime to create a new instance of our sub-typed entity:
Be aware that your new list will only show the subtype entity instances. The parent identity ‘Language’ entity list ‘All languages’ will show both! This already tells me it’s the same database table!
What changes do we see in the database? Well, have a look:
So, we see an addition of the lang_is_special column to the language identity table, and we see a s_discrimiatorid passing by where the entity TypeID of our new entity is saved! “Aha”…That’s how they can discriminate the two lists from each other!
Enough in-depth knowledge…Time for the next one!
Create a customization
Notes upfront on “customizing”:
- You create a new entity for your specific requirements (excl. functionality from the parent!)
- Name must equal the original name (you’ll get an error during deployment when not so!)
- There is an import of all building blocks for you to further customize via the replacement action
- You can add new building blocks
- There is inheritance of the ‘abstract’ and ‘re-usability’ options where both are unchangeable
Let’s create a new customization of the identity ‘Language’ entity. You’ll get a new screen to set the properties with an equal (required!) name Language. We’ll also add a new Boolean property lang_is_new (default with TRUE), exposed in the replaced ‘Create’ form, and in a new list lst_new_languages:
Same here; Don’t forget to replace the ‘Security’ BB to set the correct permissions for the new property and this list!
Save the new custom entity (in the entities folder of the project), do a first deployment, and get (again!) a translations error; You know how to solve that one now! Do a republish, and you’ll be fine to move into runtime to create a new instance of our customized entity (from within the list ‘New languages’).
The first thing I notice is the availability of the already created entity instances (the original
Languageentity and our created subtypelanguage_special)! This tells me again; they all live in the same database table!
What changes do we see in the database? Well, have a look:
So, we see an addition of a lang_is_new column to the language identity table this time. You also see that the s_discrimiatorid column does NOT get a value (although it’s a new entity type!); Again, a moment of “Aha”!
AND, this also gives directly the answers to our own questions… 🤗
A finalized “DONE” with a conclusion that both subtyping and customizing will update the current entity table in the database with additional columns. So, no new tables! I’m partly amazed, but with what I’ve seen so far of the platform it should not be a surprise; Well, there is always hope on improvement. If it’s good or bad, I leave in the middle; It’s a good learning process and this makes our decisions better when we have the choice to subtype, customize, or create a standalone entity. Have a great weekend, till next week.
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”?
