[Refactor] Move Entity operation ran as expected, but data was completely deleted from entities

Forge Component
(10)
Published on 2018-09-21 by Ricardo Silva
10 votes
Published on 2018-09-21 by Ricardo Silva

Hi,

I had my experience with the component - version 2.0.0 for Outsystems v10 last week. I wanted to move some entities from one eSpace to a newly created eSpace to break a circular reference in the existing application. I chose the refactor component to proceed to the operation using the 'Move Entity' script which was the best option to me as moving entities was the fastest and less effort choice rather than moving actions and processes.

I followed the script entirely as suggested and while publishing the solution with the Refactor eSpace plus the Source and Target eSpaces - step 2.c I got this error:

"Could not create foreign key constraint. This may have happened because there are 'ModuleId' values of entity 'Comment' with no corresponding value in entity 'StudyVersionQualityControlModule', or attribute 'ModuleId' of entity 'Comment' is creating a circular dependency between entities. Check the Error Log for more information."

with the details:

"ORA-02298: cannot validate (OSADMIN.OSFRK_OSUSR_T01_COMMENT_O46641) - parent keys not found

While executing:
ALTER TABLE "OSADMIN"."OSUSR_T01_COMMENT" ADD CONSTRAINT "OSFRK_OSUSR_T01_COMMENT_O46641" FOREIGN KEY ("MODULEID") REFERENCES "OSADMIN"."OSUSR_48G_STUDYVE3" ("ID")

from file 'CreateForeignKeys.sql' of module 'STD_QualityControl'."


Result: I queried the referred Comment entity to check if I had bad data and I have to assume that I had, but I got totally surprised when I queried all other entities involved in the Move Entity operation and they all were completely empty, meaning the data was entirely deleted!


I didn't analyze the code, but just having a quick look into the DeployEspaces action we get this piece of code in a exception handler branch with delete scripts for the MovedEntities.

Looking also in the OSSYS_ENTITY in the database:

We can see that both entities have the same Physical table name, so I'm just wild guessing that the reason behind why the data got deleted might be this. It's just a wild guess...


In the end and I will write it again all data in the involved entities was deleted. This was made in the DEV environment, so I'm not that worried about it, but I don't know if I'm going to use the Refactor again while deploying the eSpaces in other environments.

To me, the component should be reviewed, because all that matters here is moving the entities from a source eSpace to a target eSpace, keeping the data - there's no reference to what happens to the data in the script. Also, there's no reference to using or not Lifetime which probably should. I liked the component, saved me a lot of time, but unfortunately it failed...

I hope I get news from the Support Team.

Regards,

Tiago


Hi Tiago,

I'm not a component maintainer, so I don't know why this happened (even what exactly happened), but the physical table name being the same is exactly what should happen. The tool doesn't move data (or even touches data at all, afaik), but just updates the meta model so that another eSpace is assigned the Entity, instead of the original one.

Also, afaik, the tool doesn't update or touch the physical tables, so I have got no clue as to where this error originates, but I would assume (perhaps wrongly) it doesn't have much to do with the refactoring (but I'll gladly let me prove wrong by one of the component maintainers).

Kilian Hekhuis wrote:

Hi Tiago,

I'm not a component maintainer, so I don't know why this happened (even what exactly happened), but the physical table name being the same is exactly what should happen. The tool doesn't move data (or even touches data at all, afaik), but just updates the meta model so that another eSpace is assigned the Entity, instead of the original one.

Also, afaik, the tool doesn't update or touch the physical tables, so I have got no clue as to where this error originates, but I would assume (perhaps wrongly) it doesn't have much to do with the refactoring (but I'll gladly let me prove wrong by one of the component maintainers).

Hi Kilian,

Thanks for the answer. I'm aware the component or tool doesn't move or migrate any data, just uses the OSSYS_ENTITY to point a new created entity to the old one, keeping everything intact as it was before any kind of changes what so ever. This kind of procedure is quite known to me even Refactor didn't exist at the time. Nevertheless, I don't really see any reference to this in the Refactor - I might be wrong.

I'm really surprised with the result. I don't possess any kind of delete scripts to such entities in the application if any thoughts go in this direction. I have my doubts though to the result seen in the OSSYS_ENTITY where both entities have the same physical table name, because any possible script may still point to the old entity where the data still is, if an exception occurs. But again, it's just a wild guess...

As an update to what I've written before, the only entity which kept the data intact was the OSUSR_T01_COMMENT or Comment, exactly the one which has thrown the exception while it was being updated by the referred constraints script.

Thanks for any news to the presented issue.

Regards,

Tiago