148
Views
8
Comments
Solved
Database upgrade warning on deployment after deleting static entity record
Question

After deleting a record from a static entity, I recieved the following warning when deploying an app. I understand that if that record is currently being referenced in the database then it will not allow it to be deleted - or that is what I thought. It is using the Protect delete rule in all entities where is is referenced.

What is confusing is that when I go into the environment I deployed to, that static entity record is in fact deleted. Why then is it giving this error/warning? Is it because it will allow it to be deleted but now there is an Id for a record in other entities that no longer exists in the static entity - I didn't think this was possible using the protect rule.

2021-09-06 15-09-53
Dorine Boudry
 
MVP
Solution

not seen it yet, but the way I'm reading it : 

it is just a warning that the underlying database value could not be removed.  

  • Not an error, so the deploy can go forward.
  • The model (entity) can be deployed with the change, and not have that option anymore, so for your entire Outsystems application, it won't be available anymore to pick from dropdowns, or to reference in code.

It could be an interesting test to see how the application deals with those records that are still referencing this old value

It could be an interesting test to see if OS in some later deploy cleans up that value once it is not being referenced anymore, or if it will forever linger there.



2022-11-02 07-18-33
Nicholas Campbell

Thanks Dorine, thatmakes sense.

I am dealing with the records that reference it and assuming that in the next deployment, it will delete the static record completely. Will let you know here.

2022-11-02 07-18-33
Nicholas Campbell

Dorine, do you know if this separation between the entity and the database is just for statics or if it is like this for all tables? Just curious.

2021-09-06 15-09-53
Dorine Boudry
 
MVP

i have never given this much attention, but some (annoying) things i know about :

changing the order of your attributes, won't change the order of the underlying columns, that's why you have to be carefull with select * in sql, that will give either wrong output or dump after changing attribute order in your entity design

removing an attribute, won't remove the underlying column or values.  So there is some (limited) space here for undoing the delete of an attribute and having access to all the old values, a.f.a.i.k.

All of this is also dependent on what has already been implemented in any given environment, you really shouldn't do anything with it or rely on it.  Let's say you've introduced 5 attributes in dev and deleted 2, brought everything to acceptation, then deleted another one, then brought everything to production, each of your environments will have a different table definition, 5 in dev, 3 in acc, 2 in prod.

Dorine

2021-09-06 15-09-53
Dorine Boudry
 
MVP
2022-11-02 07-18-33
Nicholas Campbell
2022-11-02 07-18-33
Nicholas Campbell
2022-11-02 07-18-33
Nicholas Campbell

So it turns out that the static entity record was not actually deleted from the database, but when viewing the static in service studio it does not show as one of the records when viewed in the data tab. Sounds like possibly a bug in the UI to me...

Anyone else seen this before?

2021-09-06 15-09-53
Dorine Boudry
 
MVP
Solution

not seen it yet, but the way I'm reading it : 

it is just a warning that the underlying database value could not be removed.  

  • Not an error, so the deploy can go forward.
  • The model (entity) can be deployed with the change, and not have that option anymore, so for your entire Outsystems application, it won't be available anymore to pick from dropdowns, or to reference in code.

It could be an interesting test to see how the application deals with those records that are still referencing this old value

It could be an interesting test to see if OS in some later deploy cleans up that value once it is not being referenced anymore, or if it will forever linger there.



2022-11-02 07-18-33
Nicholas Campbell

Thanks Dorine, thatmakes sense.

I am dealing with the records that reference it and assuming that in the next deployment, it will delete the static record completely. Will let you know here.

2022-11-02 07-18-33
Nicholas Campbell

Dorine, do you know if this separation between the entity and the database is just for statics or if it is like this for all tables? Just curious.

2021-09-06 15-09-53
Dorine Boudry
 
MVP

i have never given this much attention, but some (annoying) things i know about :

changing the order of your attributes, won't change the order of the underlying columns, that's why you have to be carefull with select * in sql, that will give either wrong output or dump after changing attribute order in your entity design

removing an attribute, won't remove the underlying column or values.  So there is some (limited) space here for undoing the delete of an attribute and having access to all the old values, a.f.a.i.k.

All of this is also dependent on what has already been implemented in any given environment, you really shouldn't do anything with it or rely on it.  Let's say you've introduced 5 attributes in dev and deleted 2, brought everything to acceptation, then deleted another one, then brought everything to production, each of your environments will have a different table definition, 5 in dev, 3 in acc, 2 in prod.

Dorine

2021-09-06 15-09-53
Dorine Boudry
 
MVP
2022-11-02 07-18-33
Nicholas Campbell
Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.