Skip to Main Content
Categories Enrich Performance
Created by Ulrik Viebke
Created on Dec 20, 2024

Archive feature

Please, fill in the below fields to enable the processing of your idea.

Who would benefit?

All customer who need to remove old products, but still need an archive for historical data (and historical promises)

What impact would it make?

Increased performance for example when querying, for customers who indeed are collecting historical data (for any reason).
Deleted entities are not lost, just somewhere else

How should it work?

An entity type and segment is marked as "Archiveable".
When an entity from that segment is deleted (for example if the process is to first move the entity to a PreArchive segment), it can instead be moved to an archive. This means that the entity object and it's relationships is stored as a simple json object in a file archive or a database table. This means that even though it is deleted from inriver pmc databases, it can still be brought back to life if necessary.
An archive view would allow you to search in a flat structure based on displayname and displaydescriptions, and potentially other data, and a de-archive would basically bring the entity back to life again as a newly created entity with same data and same relationships (and removed from archive).

Should an archived Resource will also archive the binary? If so, this has to remain in inriver asset service, but maybe it would be possible to restrict historical assets from being deleted from the blob container if the Resource is archived. This must however be clear that archived binaries are part of the data storage capacity in the licence agreement.

Why is it needed?

When data is deleted in inriver, it is gone forever. Customers why need historical data tend to keep them, but probably just in another segment. This means that the performance degrades over time.


Additional feedback, background or context:


  • Attach files