Refactoring tooling.....!!!!!
This continues to be really relevant!
It absolutely does.
Great idea, especially when you want to split out functionality and use it as a shared component.
Yes, this feature is useful especially refactoring the code
Hi, There is ANY reason (besides other priorities) to this to not have being implemented as part of the platform yet?Move entities from one module to other is absolute essential when doing refactoring, and it poses lots of problems...Anything other than change metadata information is required in order to do this?
Agreed. The refactor forge component is a waste to use. Its not helping really because you need to do roughly the same amount of work.
Refactoring means better quality for the developers and customers because you can create more seperate apps...
Sounds like we're all on the same page. I know the ability to drag and drop an entity exists, but no data transfers. That's the real need: move an entity with data from one module or eSpace to another. Is it possible to do that from the SQL backend?
We really need this...
I just wanted to submit this as a new idea. I don't understand why this is still not in the product after more than 8 years. I believe that when your are building large landscapes, proper support for refactoring is essential.
Agreed!! Same issue when moving Roles from one module to another - the original role Id's are replaced by new ones and users no longer have the effective roles they should. HUGE PROBLEM.
++ For native re-factoring support for entities AND roles! Need this yesterday OutSystems!
Currently if you copy an entity from one module and paste it into another, none of the data is transferred. It would be VERY helpful to have the option to include copying across the data for that entity as well.
When you change module of the entity, their reference tables will also gets recreated. This is huge data loss. We were new in the outsystems and now we have to refactor our code to avoid circular dependency and improve product support. But we cannot compromise with data. it will be very helpful, If there is any workaround for now.
Hi Mayur,
When refacturing, the trick is to keep the current eSpace as data eSpace, and move everything non-data-related to other eSpaces. Of course, if you have created circular references between Entities in different eSpaces, this is not a solution. There's also the Refactor Forge component that may be a solution.
Mayur, I believe there is a data extractor on the Forge that you might be able to use to extract the entities into excel files or similar and then you can bootstrap them into your new module.
HTH, Sienna
+1
Since this is an idea with almost 10 years, created by one of the company's founders, I'd say it would be a nice thing to do ;)
Best regards,
PC
Hi !
It is very important that Outsystems provide official solutions to support the architectural evolution of applications. With a solution to this need, we will be faster in evolution.
Best Regards,
Alberto Granja
Outsystems has introduced Service Actions, Architecture Dashboard and other tools to support healthy applications that can scale with the power of low code. Entities also need the same love otherwise developers/architects are still missing the support to scale/maintain growing applications
Guys... this was created 10 years ago, cmon.. let's do this.
+1 good idea!!!
This feature would be very useful when it is necessary to refactoring old applications that didn't follow best practices in terms of architecture. At the moment, the process of migrating tables between eSpaces is a very time-consuming.
C'mon guys, we need this!! :)
Hey guys!
2021 reminder that we need the platform to help us with the refactoring process. Each time I have to use the forge component my life expectancy drops by at least 6 months.
As others have mentioned, this was initially flagged well over a decade ago. Anyone know how long it's been marked as being on their radar?
We are often faced with scenarios in which we need to refactor applications.
Sometimes we are able to move some elements to a new module by renaming the old module to keep the entities with their data, since if we create an entity (Even with the same name), in another module, we lose all its data, because to the system it's a new entity
There are currently some components in Forge like Refactor that allow us to change the location of the entity while maintaining the data.
However, it would be very interesting to have this native functionality in Service Studio, so that it would be something simple, like right-clicking on the entity and choosing something like changing Module.
That way, refactoring and maintaining a consistent architecture would become much easier in some scenarios.
This is an extremely necessary tool/functionality.
Even having the forge component in order to refactor an aplication, that component is not 100% complete because it does not comtemplate static entities data.
I recently had to procede to an aplication refactor due to circular references, wich included some static entities. And with that forge component limitation, i was forced to manually migrate the data from the "old" to the "new" tables in all environments in order to maintain data integrity.
This procedure was a big time consumer, and so, if OutSystems provided a mechanism to simply move the entities and its data to the new module it would be a huge huge help in order to simplify the refactor process.
Improving the refactoring process in this sense is too manual a task:
Our factory is getting bigger and it costs us a lot to refactor it, almost exclusively because of this and we do not see the sense of such a complex process, just to move tables between modules
There should be a feature to move an entity to another module within the same application.
I have a module (lets call it ABC module) started simple and has an entity that extend User entity with additional info (lets call it UserInfo entity).
As time goes by, this entity is now leverage by more and more modules and any enhancement on ABC module will gives dependencies warning to all the modules that leverage UserInfo entity.
With the above feature implemented, people can split out their entities and adapt it accordingly.
Hi Budi,
there is a Forge component with that ability:
https://www.outsystems.com/forge/component-overview/496/refactor
Hi,
For refactoring purposes, many times we need to move entities form one module to another, trying to modulate the architecture. The main problem is, that, at this moment, we don't have a simple and fast way to do it, like cut from one module and paste it in another (in the case that we already have data).
I think (based in that the "Entity" is an abstraction of the DB table, that persist in the DB), that Service Studio could give us that possibility. At least if the modules are from the same catalogue. It can be a great improvement for refactoring purposes.
Ricardo Pereira
Hi Ricardo,
Did you use the Refactor component to move entities?
Regards,
Daniel
Hi Daniel,
Yes, I used it once, and I believe that the proposal that I made is much more easier and fast to do the job. And, I believe that many of us don't do the needed actions many times because of that, doesn't having a fine and easy solution. I believe that, as a low code platform, with accelerators for everything (or almost everything), this could be a great update.
I 100% agree with Ricardo. Must be an easier way to make it. The Refactor component is a solution but not the most practical.
Regards
100% agree with Ricardo. We passed this problem lots of Times. If we have a solution on service studio, it Will be fantastic.
BR
Another fantastic useful idea, I agree, it would be much easier than the Refactor component
OutSystems AI Mentor tells us to fix Monolithic Modules and there is no actual way to do this if the module in question is a Core Service Module with mixed business concept. For an app already in Production needing to do a data migration because OutSystems is unable to move/rename entities without creating a new table is very frustrating, only the OutSystems metadata needs to be changed the physical tables in the database shouldn't need to change in any way. To note this idea is 13 years old and no action was taken on this.
obviously nowadays there are workarounds to avoid losing data with refactories, but it makes the work much bigger and less precise.
This feature would be great.