Data Entities in Cloned Application

Data Entities in Cloned Application

  

i'm curious, if i clone an application, do all record of data in the entities will be cloned as well? 

thanks

Hi

No. When you publish the module, new tables in the database will be created.

Cheers.

hi eduardo, then how do i get the data? is there any way to export the entities to excel?

thanks.

Solution

Hello Ervin

Yes, it is possible to export data to excel:

https://success.outsystems.com/Documentation/Development_FAQs/How_to_export_entity_data_to_Excel

You can also create a module that references the entities of both modules and copies data from one to the other.
Etc.

Cheers.

Solution

Hello Eduardo


Can you give more details about your last sugestion: You can also create a module that references the entities of both modules and copies data from one to the other.


TIA

Hi Alberto.

If both the original and the clone modules are in the same server, you can create logic to copy data from the entities from original to clone entities as you can reference them in both modules.

You have to pay attention to Identifiers/foreign keys, of course, but this is also true with excel export, because in the new entities, the IDs will be probably different.

And this will give a lot of work, possibly.

There are at least one commercial solution to migrate data (Dmm something).

If ypu have access to database, you can try to do the copy directly there... I suppose.

Cheers

If this hapens a lot then you may want to consider splitting your business logic and entities into separate espaces, We place business logic into an espace called XXXXXX_CR and entities into one called XXXXXX_ENT with the only code in the _ENT being stuff that does nothing except updating the data. This way you have the option to clone just the user or business logic espaces and point them to the same entities OR you can clone the Entities as well therefore allowing a lot more flexibility.

The other thing you can do is use the AdvanceQuery component and write an SQL select into statement to copy data from one entity to another ( https://www.w3schools.com/sql/sql_select_into.asp ). However be warned as with Eduardo's post above this will most likely affect your ID values so doesn't work so well with linked entities.

Hi all,

@Alberto,

You can also make use of the Refactor forge component to guide you and help you migrate entities (with data) from one module to another. As stated above, it does require considerable effort, so it's always better to get it right "the first time" if you can ;)

This will basically be a guided version of what Eduardo suggests, and will allow you run your data copying as well when you deploy the new version of your application to the next environments.

@John,

What's the benefit you see in separating logic and entities/data that way?

The effort of separating in two modules and refreshing dependencies might offset the advantage you see when you clone (how often do you clone your modules??), besides the effort of cleaning up a clone of a module that has logic and data isn't that much is it? just delete a lot of stuff, reference deleted stuff from original (or from another clone), and the platform re-links everything if it has the same names...

Jorge Martins wrote:


What's the benefit you see in separating logic and entities/data that way?

The effort of separating in two modules and refreshing dependencies might offset the advantage you see when you clone (how often do you clone your modules??), besides the effort of cleaning up a clone of a module that has logic and data isn't that much is it? just delete a lot of stuff, reference deleted stuff from original (or from another clone), and the platform re-links everything if it has the same names...

Main reason we separate it is to help enforce the 4 layer architecture and circular references etc. We have a huge number of interrelated espaces and applications and often the business or user logic of one needs to access the data of another. So to ensure we don't end up with circular reference issues we separate them. The cloning part is just an additional side benefit but does allow us to "branch" code by cloning business logic and re merging when we need to. 

Also makes it easier to do thing like make global reporting applications that only need to link to the data not the full business or core espaces


I understand having business-logic only core modules, that depend on multiple core modules (that expose the different non-entities needed), and also if the pace of change of entities and their accompanying business logic is different; but separating entities and closely related business logic may also lead to circular dependencies down the road: if your _ENT modules' actions that just update data need to perform extra business validations, they might require functionality implemented in a _CR module, that references the _ENT module. How do you account for these situations? Mind you, not questioning your architectural solution works, just wanting to learn how you make it work :)

Jorge Martins wrote:

I understand having business-logic only core modules, that depend on multiple core modules (that expose the different non-entities needed), and also if the pace of change of entities and their accompanying business logic is different; but separating entities and closely related business logic may also lead to circular dependencies down the road: if your _ENT modules' actions that just update data need to perform extra business validations, they might require functionality implemented in a _CR module, that references the _ENT module. How do you account for these situations? Mind you, not questioning your architectural solution works, just wanting to learn how you make it work :)

No problem, get the same questions when we onboard new devs :) 

A lot of this was learnt the hard way when we had to unwind a lot of cross and circular references and just couldn't find where certain code lived, we even got Outsystems themselves to do a full review on how we built one of our very first projects. 

We basically have a list of espace post-fixes and define what is permitted in each. _ENT is just data and CRUD actions and an _ENT cannot reference anything other than another _ENT (although this is lightly discouraged as links between _ENT's are normally due to business or user logic but sometimes are needed just for reference ID's ). _CR contains business logic and can reference multiple _ENT's. _CR's are also permitted to combine business logic and entities where there is a very tight link, not a lot of entities or the entities are not exposed as shared at all. 

We also do ones for dedicated "shared" webblocks (_WEB), API's, Low level infrastructure. As well as an additional "S" (ie _SCR,) to signify that the espace is heavily shared between applications, these "S" espaces cannot reference a non "S" espace, so effectively _SCR is at a lower level to _CR ie _CR can reference _SCR but not the other way round. 

Main problems we are trying to solve with this are

* Break the 4 layer architecture into sub layers by defining what espaces can reference others

* Make it easier to find things for new developers, you want to find where a REST API is consumed you look in the _API, data in the _ENT, etc.

* Break large projects up into smaller pieces so that it is easier for multiple developers to work in the same application without doing excessive merging 

* above all have a clear fixed pattern so that an application can be maintained in 10 years time (our older non Outsystems applications are still in maintenance after almost 30 years)

We currently have 13 different espace post-fix's in our standards document, each one with set rules on what they contain, what can reference them and what they can reference. Since implementing this we haven't had any circular reference issues except where a dev hasn't followed the guidelines.

This is all probably major overkill for most Outsystems developers but at the moment in the dev environment we have around 5500 Application objects and more than 800 individual espaces of which 12 developers need to be able to maintain any of them. Plus we are bringing on new devs all the time, many of whom have no Outsystems experiance.

As to the having to refresh references all the time it isn't actually that bad, we find that the underlying data structure changes a lot less than the business logic which changes less than the user logic. This systems also makes unit testing a little easier although we haven't implemented that yet. 

Oh plus I'm a control, freak :)

WOW, now that's a nice, detailed explanation!

Looks like you have a whopping 13-layer canvas! and it also seems like you need it ;)

I'm wondering, do you have any automated way of checking your rules for violations (similar to what Discovery does with the 4-layer canvas)? or you have to rely on code reviews?

Oh plus I'm a control, freak :)

Well... you're using OutSystems, you already relinquished a lot of control to the platform, there's still hope! ^_^

Discovery is still useful as we still categorize everything into the 4 layers and it picks up issues such as circular or _CR's accessing _USR's but your right it doesn't do everything. At the moment we pick up the rest of the issues with code reviews but an automated check is in the ToDo list. 

Combine this with enforcing the entry of descriptions against all entities, shared actions, webblocks etc and then run OutDoc across it and it's actually quite easy to do a code review and everything almost documents itself.

Thanks to all for your contributions. Very enlightening Discussion!!