Hi Doug,

I tested and in fact that is the behavior - if you have already published the eSpace, you cannot change the ID of a static entity record.

To avoid the error, all you have to do is, instead of "changing" the existing TypeC record, deleting it and creating a new TypeD record.

Of course, you'll then have to change the occurrences of TypeC by TypeD to have your eSpace valid.



I tested it, and it worked without problems.

Regards,

Daniel Lourenço
OutSystems

Daniel,

Thanks for the swift reply (on a Friday evening no less!)

I've also tried this and it is now working... The problem is that I have a few to update and I'm having the problem on each time I try to upload/compile to a platform (that has had the previous release on it).


I it is getting tedious and there seems to be no logical reason for it.


Rgds,
Paul. 

Hi Paul,

I think a good reason for not being possible to do this update is the fact that it can has a big impact on your datamodel (if you are updating the ID, this will affect all the references that use it and it is not clear how you would want it to behave). Nevertheless, be sure that your feedback is welcome.

The best way to avoid this situation is to use an integer autoincrement ID key together with your label (working as a surrugate key). This way you will be able to easily update the labels (because now they work merely as labels, and not as IDs).

Kind Regards,

Daniel Lourenço
OutSystems

I would like to say that there's a bug on Static Entities because when I publish the eSpace in one environment, it creates the ID and when I publish the same eSpace in a different server, it ignores completly the ID sequence, and adds the static values in a different order.
What happens is that I had TypeA with ID 1 on one server and ID 3 (for instance) on the other.

This causes huge problems when you need to import data from one server to another.
This really happens, because it's how I did discover this bug - in October we moved our applications to a Datacenter, so I first published all eSpaces and then wanted to import data.

We had a deadline so no time to think about it. We quickly removed all Static Entities from our projects and don't use them anymore.
:D

Hi Carolina,
Thanks for the feedback. I assume you were using AutoNumbers as identifiers for those static entities right?
If you set an attribute as an autonumber then that order is not maintained. When you want to use that to migrate related entiteis between environments you should use normal integers (or text) as entity identifiers, fill them up in the espace/static entity, and relate foreign entities to that.
The IsAutonumber attribute has the same behavior in static entities as in normal entities - the identifier is given by the database.

Hi Gonçalo!
Thank you for your message!
Yes, it's autonumber and I totally understand what you say...
But when a Static Entity it's created, it comes by default: ID (integer and autonumber), Label and Order....
So to avoid this, the ID should not be autonumber as default, then the eSpace will remember the correct IDs always.
Otherwise this problem will remain forever and when you need a migration, your database won't be ever consistent.
Because even when migrating data and moving everything - also the original IDs - when you publishing the eSpace again, it changes back to the original IDs - mixed ones.
:D
This is a bug and you lose control of what is in your database when you need migration. What is super dangerous.

This comes back to a Wisdom of the Crowds entry I've seen requesting ways to migrate data from one server to another. I think that this functionality should be included in that.

Alternatively, I think this says that there may be an opportunity for someone to write an import/export system that takes this into account?

J.Ja

I think it's more to update OutSystems to remember the correct IDs as well (making it not autonumber, for instance) and not the import routine itself.