Why a new database attribute is created when you rename it in Service Studio

Why a new database attribute is created when you rename it in Service Studio

Some people note that the OutSystems Platform will create a new attribute in the database when you rename an attribute in Service Studio and find it odd.

This is not a bug, and is indeed documented behavior. But even when confronted with this, people find the behavior odd.

The principal reason for this oddity is the requirement (guarantee) that publishing a module in the OutSystems Platform will not break the behavior of another module even if the module being published is a producer and the interface to talking with that module changed.

For example, if an attribute rename in Service Studio were implemented as an attribute rename in the database it could be the case that another module, using that entity, would become broken. If the specific attribute were used in the module, the compiled queries* might become invalid as they are referring to a non-existing attribute.

An alternative solution for this would require that consumers of an eSpace be updated and recompiled for the new definition of the entity. With this change, other changes in the producer module would need to be handled at the consumer module. This could have cascading consequences in your factory and require you to go through the entire factory to update all consumers before you want/are ready to, hindering your "agility".

Summarizing, this behavior ensures that a simple change in one module does break anything else in your factory, and that you don't have to propagate changes in one producer module until you are ready and willing to do so.

However, it's true that these changes can't be taken very lightly. In a production scenario where the attribute already exists in the production database with the previous name, it is often undesirable to lose the data that is already in the column. For these scenarios we recommend a two step approach:

Step 1) publish a version of the module with the old and new name and in an On Publish Timer copy the data.
Step 2) publish the final version of the module with only the new name

In before "I could do this better": This is the behavior that was discussed and implemented when this need was first noticed. It certainly not the only way these requirements could be met, but it is certainly one of the simplest and which adds least dependencies. This ensures that the OutSystems Platform code does not inadvertedly break for weird reasons.

* queries are generated during compilation time and not changed at runtime, for performance reasons. 
Hi Ricardo,

Thanks for your informative post.

But - the peice of the puzzle missing for me is how to remove columns from the database once it is no longer needed. Tried using an advanced SQL, with an ALTER TABLE blah DROP COLUMN blah, but get an error about permissions (See attached screenshot). How do we run DDL in out-systems?

Hi Dan,

You can do this by using the DBCleaner API.
Hi All,

Since the documentation for DBClearner API was written, the module has undergone a complete redesign. The Current version provides downloads for SQL files with the scripts that need to be run. These contain such statements as ALTER TABLE and DROP TABLE and refer to tables by their extended name.

Without access to the database directly, these scripts cannot be run as Outsystems blocks us from refering to these tables.

Hello Sea,

Please don't confuse the DBCleaner_API API provided and supported by OutSystems and the DBCleaner component, provided and maintained by me (a member of the community).

Also note that the DBCleaner API is only available from version onwards. Previous versions of the OutSystems Platform did not have the API at all.

I would also like to note that it is possible for you to request OutSystems to provide you with a user to access your OutSystems PaaS Environments' database who has enough privileges to execute the script generated by the DBCleaner component.

Finally, I am fully aware of the new capabilities introduced by the DBCleaner_API and intend to release an update to the DBCleaner component which leverages this API to provide more convenient database management.

Ricardo "ardoRic" Silva

How do I get to the DBCleaner_API?
It is included in the System Components of the OutSystems Platform from version onwards.
It is not on the Add/Remove References list and I am using the latest Service Studio version. Is the Environment required to be as well?
Yes it is.
Hi Ricardo,
  Do you know why the Service Studio not create any record in osusr_entity_attr when I changed the attribute name? 
  For example:
1) Create an entity named TESTE with "Id" and  "name" attributes;
2) After publish, we have in the DB 2 fields and 2 records on entity_attr
3) Rename the attribute "name" to "name_client".
4) Now, we have, after publish, 3 fields on DB, but in entity_attr the Service Studio just renamed old record "name" to "name_client". I think that the old field will be marked with is_active = 0 and a new field created with is_active = 1;
5) This behavior not permit that the dbcleaner_api removes the physical field on database, because have no correspondent record in entity_attr. The dbcleaner just searches attributes with is_Active=0. It's correct?
6) In this case, we have a dangerous situation: Lost data, in production enviroment, after rename an attribute. We need to control this out of platform.
Hmm,  never saw this thread :)

Anyways, I do understand the mechanism behind it and actually love it.
But it would be cool to have some overwrite when the platformserver is in development-mode?
Too often in early stages you rename attributes.
move them about and you are stuck with warning if you don't do the dbcleaner..

Just some food for thought: I'm aware of the technicalities underlying this decision, and agree with them, but if a developer has to create a timer to copy data between columns then the truth is the Rename feature is no rename at all. It's an usability issue...

this is an old thread but it is still valid. I fundamentally disagree with your base argumentation but it is not important now. But why not to implement (in the deployment process) a feature to copy data between old and new columns? I think there is no reason to not to know that the column B is a renamed column A....
The suggested scenario (create / delete attributes instead of renaming + an intermediate deploy to ALL production environments) is NOT always possible (and it is just ugly...)

Hi Readers,

Just to add to the above comment. An intermediate deployment is often impossible if you are deploying the product to external clients as in many cases not every release is applied in order on the client's side.

In our case, we simply deploy to the client when our deliverables are met and then deploy to another client when their deliverables are complete. There is no global release and it would not be viable to arrange one.