At present it seems that if an app is re-imported on the same Tulip instance, a new dedicated set of table queries and aggregations is created if there are any such things used in the app in question.
Please make apps reuse the existing aggregations / queries if nothing was changed.
@sebme I totally agree on this.
To give a bit of background on this our project work with a environments; development instance, testing/staging instance and a production instance. For more complex design or corrections we export/import the apps back to the development instance, and then start moving the app forward to next instances. This idea of making new queries and just appending â(restored)â as seen on below screenshot is a nuisance. I made below example to show to other users what to look out for. If someone exports a previously imported app - which introduced duplicated queries - you end up having ⌠(1) ⌠(Restored) (1) as shown below which is just confusing everybody.
Essentially after import we need to manually clean up and reapply the original queries and delete the not used queries. If someone archived apps due to wrong import then it appears that an archived app can still block deletion of the query.
Considering the concept of having validated our app in the test/staging environment we basically do not want to fiddle with the app after import into target system.
To add another nuisance to same import topic:
I also do not understand why import marks all record placeholders as âSave for analysisâ even if the export was not configured for that. We have record placeholders which are used for displaying data and are not intended for analysis and record history. We have to manually check if the setup is correct after import.
Spot on! Thank you. I am not the only one - relieved. To your point with the table records⌠I figured this out by looking into the export JSON⌠there is literally no mentioning of the Table Records analytical settings. So whatever you select there is not exported. Hence, nothing can be imported back 
I then reached out to support asking for clarification and they confirmed the observation.
Hi,
Were you be able to sort it out? What is the best practise here? Because basically I`m facing the same issue right now.
Simple answer: no It remains a standing issue.
Hey all,
As a GxP customer with multiple environments (Dev, QA, Prod) we also encounter the same issue as you describe when exporting an app from production, modifying it and validating it in QA, then when going to import it back to PROD we see the duplicate aggregations/queries. This is a fundamental issue (a major CON) for our app lifecycle process that we face and it makes the app updating/validation process even more complex and cumbersome. There is a high likelihood that a developer could miss one of theses âcleanupâ steps. Not to mention when the original developer moves on to a different role some tribal knowledge of the apps function/logic will be lost and cause a huge headache for the next person tasked with updating the app. Hoping for a fix in the near future!
(@ecarpena can also comment here on his experience)
Hi, as @alec.giljohann mentioned, being GxP we need to move apps around different instances. Once import all queries and aggregations are duplicated and some of them get the word (restored) appended to the end see a screenshot bellow. This behavior has become unsustainable. As @ASharp-J mention we also do not want to cover any gap after import into target system.
Hi, due to this issue we currently set up our environments like this:
1.We do changes in PROD
2. Export app to TEST instance to do the tests.
3. If okay approve on PROD
4. If okay delete on TEST
5. If okay use app using looper running API call to delete query by query from table.
6. Delete the app on TEST
Tulip Support confirmed that they are currently working on new way of importing the apps and one of the main features would be and I quote : âIt wonât create duplications of the table queries and aggregations - it is a minor bug, but can be very frustrating with the current app export-importâ
Since last year we do the same as Jacek to circumvent the import tool issues. It now clutters up our test/staging system instead. We donât archive the apps in test environment, but keep them in a âImported from productionâ app group so we can locate the previously tested versions. Then we can also use them to test LTS upgrades prior to deploying to production.
At some point we will have to do a cleanup exercise. As Tulip GUI will not allow removing queries and aggregations in use for decommissioned / archived apps I plan to check if I can remove using the API instead.
