Big news! The community will be moving to a new platform April 21. Read more.
Big news! The community will be moving to a new platform April 21. Read more.
Vice Admiral
Vice Admiral
898 views

difference between artifact delete and purge

Jump to solution

Whoever wrote the pop-up tooltips in the SSC for the artifact DELETE and PURGE button needs to realize that the details fall into a framework known only to the developers of the product.  A user of the product needs to know the difference between the two buttons, but none of the described properties in the tooltips match against each other between the two buttons.

1 Solution

Accepted Solutions
Micro Focus Expert
Micro Focus Expert

You bring up some valid points and suggestions. I will pass this post on to product management for further review.

View solution in original post

6 Replies
Micro Focus Expert
Micro Focus Expert

See if this is a better explanation for you:

Delete = Undo Upload
Purge = Recover Space

clipboard_image_0.png

0 Likes
Vice Admiral
Vice Admiral

Thanks, but this text seems similar to what I see in the tooltips of the 18.20 SSC.

Just providing details does not explain the difference.  It's as if someone asked a question, "what's the difference between apples and oranges?" and received an answer, "well, apples have thin skin and oranges have a soft core".  The answer looks internally (locally) consistent but does not always address the purpose of the question.  The person asking it maybe interested in an attribute (dimension) to which both objects relate.  For example, "how thick are their skins?" or "how soft are their cores" or "how do these two measure in taste?" or "do they have pits?".  So what I would expect as a good answer reads "Apples have thin tight skin but oranges have thick peeling skin" or "Apples often taste more sour than oranges but it depends on the person, apples and oranges".

Reading the generalized answer, "undo upload" vs. "recover space" sends me into a thrill of rage.  Obviously, undoing upload recovers space and vice versa.  Removing "any trace" of the artifact purges it, n'est-ce pas?  This also removes "cross-references".  Giving directions to the user where explanation (description) is expected is just a blatant abuse of style.  Saying that SOME purged artifacts cannot be deleted after the purge operation just adds confusion.  Is this a reference to an internal limitation?

0 Likes
Micro Focus Expert
Micro Focus Expert

Then let's turn the question around, what are you looking to do? What are you wanting to accomplish? This will allow us to recommend which would be better in your situation.

0 Likes
Vice Admiral
Vice Admiral

As a user/admin of Fortify SSC I have little regard for artifact history. 

On the other hand, I want SSC to take care of the disk space.  For example, instead of introducing the DELETE/PURGE dichotomy, get rid of both and present a radio button in the Administration section,

(*) Automatically purge the oldest artifacts when free disk space reduces to 5% of the entire volume.

( ) Turn SSC into a read-only mode once the free disk space reduces to 5%.

 

On a related note, consider the backup/recovery needs with SSC.  In my SSC usage scenario, we publish new static scans automatically from build machines as part of continuous integration.  In this usage, I would prefer backing up just the manual entry work (issue suppression and comments) to backing up the entire database that takes half-hour and tens of gigabytes.  This could look as easy as a pair of buttons in the Administration section and a pair of calls in the API,

[Save issue suppressions in all project versions]

[Load and merge issue suppressions with all project versions]

 

Now that I shifted concerns from artifacts to suppressions, why not consider a desperate need for automatic propagation of issue suppressions across versions of a project?  This could look as simple as a checkbox in the Administration section,

[x] Automatically propagate issue suppressions

If the issues are identified via a hash of the non-blank source code lines surrounding the data flow, the above propagation could stretch as far as other project names.

 

Micro Focus Expert
Micro Focus Expert

You bring up some valid points and suggestions. I will pass this post on to product management for further review.

View solution in original post

Cadet 1st Class Cadet 1st Class
Cadet 1st Class

I have a different use case but also need to better understand what a purge leaves behind in the DB (vs a delete which should remove all traces of the artifact).

I have 8 years of artifacts and have to implement a data retention program so I need to start deleting artifacts that fall outside of the retention window.  I've been testing this and after SSC chews on the delete request for a couple of days it throws an error.  The result is that I may have to fallback to purge for this. 

I can see that some tables have records related to the purged artifact are updated but I don't know what else I have to go in to cleanup post-purge to completely remove the artifact.  Where else should I look?

The issue here isn't space reclamation but removal of all traces of the artifact.

Thanks.

 

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.