The lifecycle of elements and devices may be less than the TTL for a database entry.
In the event an element is removed from DataMiner, what is the most efficient route to present historic data which may still exist in a database?
Preferred option would be a LowCode app.
Architecture recommendations of not removing an element and potentially archiving (in a stopped state) could be an option
Marieke Goethals [SLC] [DevOps Catalyst] Selected answer as best 23rd August 2024
As this question has now been inactive for a very long time, I will close it. If you still want more information about this, could you post a new question?
Hi Ian,
Has Meekaeel's comment been helpful for you? Or have you been able to find a different approach in the meantime?
Marieke Goethals [SLC] [DevOps Catalyst] Selected answer as best 23rd August 2024
Hi Ian, recently I developed a work around for this issue as a customer wanted to retain data from entities even after an element is removed or after the entities are removed from the table they resided in. What I did was leverage an automation script to query the cassandra database. In order to do that you would need query it with the entity’s partitioning key which is a combination of (dma id, element id, parameter id of the value you want, primary key, and window). More info about querying cassandra is found here https://docs.dataminer.services/develop/devguide/Connector/AdvancedDataMinerDataPersistenceNoSqlCassandra.html#data-table . In order to keep this data so that when the element is removed or entity is deleted I added logic to export a file with these values needed for the partition so you can leverage the info after an element is deleted. If you have questions on how to implement this or if it seems relevant to your problem feel free to reach out to me on teams or via email.