|R8254: Slow Opening of Collection with many Post Operations|
In a collection with many posts, it can take a very long time (30 minutes or more) to open the collection in User Mode.
When a post is attached to a view, Helix RADE evaluates the setup and, if it passes the test, a flag is set in the view indicating that that posting setup has been tested successfully. When a post is subsequently changed, all views that reference that post should be flagged so that they retest the setup to make sure the posting is still valid.
One bug that has existed in prior versions of Helix could cause that flag to not be set, so that the view would proceed under the assumption that the post was still valid for use with that view. While that is true most of the time, there may be cases where the view is working with invalid assumptions.
In addition, it is possible that changes to other icons (fields, abaci, other posts) can ‘cascade’ up to the post, making it no longer valid for use with a specific view. The typical example of this is a post that uses an abacus that calculates its value in part from a field that is the target of another post. Those two posts may not be used at the same time on a view.
During the conversion of Helix RADE to macOS, it was determined that it was possible to re-evaluate every view each time the collection is opened, and the performance impact was negligible. Consequently, Helix RADE 6.2 (starting with 6.2b8) does not consult that ‘valid posting’ flag and makes no attempt to reset it when structural changes might render it invalid or when subsequent use of the view proves that it is valid. The theory was that we could recalculate that information as needed, avoiding the possibility of errors due to a bug.
However, after the release of Helix RADE 6.2, a customer came to us with a collection that was taking well over 20 minutes to become useable when opened. Our investigation discovered that this collection makes heavy use of posting — at least one view has 99 posts attached to a single action — and that the shortcut we adopted would not work in situations such as this.
If you change the preference described below, it is critically important that you also run the script to confirm that all views are properly set up. Failure to do so may result in views that fail to post as intended or possibly crash during posting.
First: if you are not experiencing a period of inaccessibility after opening your collection, you do not need to apply this solution.
If your collection does take a long time to become accessible, the solution to this problem is twofold:
We have developed an integrated solution in the form of an AppleScript that fully automates the correcting of this problem. To address this issue:
The script changes the setting, prompts you to open the affected collection, and then corrects the flag settings for each view that uses posting. When complete, a dialog reports on the number of views found, the number of views with posting, and whether all attempts were successful.
Once you have run the script, it is not necessary to run it again, unless you subsequently work on the collection with a version of Helix RADE prior to 6.2.1.
Our Helix Preferences Editor (available on our AppleScripts page) has been updated to enable direct control of the HxAlwaysValidatePosting preference.
The underlying bugs exist in various versions of Helix RADE prior to 6.2.1, including Classic versions.
The ‘slow opening’ situation exists in Helix RADE 6.2 and later — starting with build 5765.
A future release of Helix RADE will apply a permanent situation to the issue. At that point it will not be possible to open a collection with earlier versions of Helix RADE. The status of this issue can be tracked in R8254 of techdb.