When you create a Static Entity in OutSystems the default configuration for the Id attribute has the Is AutoNumber property set to Yes. Unless you are going to change that to be a Text Identifier the first thing you will want to do with any new Static Entity is change the Is AutoNumber property to No.
“But Greg,” you say, “why would OutSystems make that the default if it’s so bad?” |
I don’t have the answer to that, but I do have three reasons why you want to switch Is AutoNumber to No.
Reason 1: Keep the ids consistent with existing values from legacy code, external systems, or APIs
Unless you are building the world’s simplest app, you’ll need to integrate with some external code base at some point. Whether it’s legacy code in your ecosystem, an external system, or an API, they all have one thing in common: you can’t change them. If your integration with these systems needs a Static Entity to map their code values, then you’ll need to match them. Setting Is AutoNumber to No is the obvious choice.
“Well duh Greg, that seems pretty obvious, but I am building the world’s simplest app, and I don’t have any integrations, so why do I care?” |
Consider this as we head into the next reason: what if your app becomes the integration point in the future?
Reason 2: Id inconsistencies across your environments
Imagine the following scenario. You’re creating your app in dev, and your new Static Entity has Is AutoNumber set to Yes. You add a handful of records that you anticipate needing. For example, let’s say you add four records: Ford, Chevy, AMC, and Dodge, in that order. You publish, and the ids are assigned as follows:
First, notice how the ids aren’t necessarily in the same order as the order of your records. Not what you expected, is it?
Now let’s say as you are developing your Product Owner says, “AMC has been out of business for years; get rid of it and add Honda and Toyota instead.” So, you do that and republish. Now we have:
Now AMC with Id 3 is gone. We’ve finished our development and are ready to migrate to the Test environment. After the deployment finishes, we have:
So now we have two very different sets of ids between our environments. 60% of the records have different ids. Seeing as Static Entity ids are often used as foreign keys in other Entities, this would cause a major problem if you ever needed to migrate data from one environment to the other. The foreign keys would be mismatched, and in the case of a missing id like 3, you would get a foreign key exception trying to insert that data.
Remember the point I asked you to consider before? What happens if your app becomes the integration point in the future? How will you document what the different values represent? “In Test 3 means Ford, but doesn’t exist in Dev. 2 means Chevy in Test, but 1 in Dev.” The people integrating with your software across the different environments will want to pull your hair out!
“Wow, that’s interesting Greg, but like I said it’s the simplest app in the world and I won’t be migrating data or creating integration points.” |
Fair enough. Let’s look at reason 3.
Reason 3: Id inconsistencies after refactoring
Imagine your app is now in production, and everything is great. However, you’ve been tasked with creating another app now, and that app needs to use your previous static entity. Since you are a good OutSystems developer and like to follow proper architecture best practices, you decide to refactor the original app by moving the Static Entity into a common module that both the original app and your new app can share.
Uh oh! For the reasons mentioned previously, the ids in the new common module don’t align with what they were before! So now that you’ve referenced the new Static Entity in your original app, you are getting foreign key errors on publishing, or worse: no errors, and the previous data now points to values that don’t mean the same thing they used to.
Now you are in a world of data fixes, and your productivity gains from using a low-code tool like OutSystems are obliterated trying to fix something completely avoidable by using Is AutoNumber set to No.
“Yikes! Thanks Greg, I’m convinced! I’m going to start setting Is AutoNumber to No from now on!” |
Good, and don’t forget this very important bit: you need to set Is AutoNumber before your first publish! Otherwise, the identifier will be set, and there’s no way to change it. You’ll be stuck needing to create a different static entity and swapping out all your references.
