I hope anyone reading this can share their experiences with managing
similar issues...
We have several enterprise EDG projects (taxonomies and ontologies) whose
".tch" change history graphs are getting very large, since they have been
actively edited for several years now. Separately, we have a large number
(1000+ workflows per project, for two of our projects) of committed but
un-archived workflows. These two conditions seem to be slowing down
performance in several areas:
- Loading the list of workflows
- Loading the change history for an individual resource (this is
painfully slow now)
- Sending these projects to another server (if we do choose to also send
the .tch files)
- Updating the projects available to Explorer users. (EDG seems to
automatically send the .tch file when you do this, but if it were up to me
I would choose not to, since the change history is not relevant to our
Explorer users.)
I am considering different methods of archiving working copies and reducing
the size of our change history graphs, including:
- Activating the "Archive Working Copies on Commit" option... but I have
several questions around what this entails:
- Will doing this automatically archive all our already-committed
workflows? If not, is there a way to do that in a batch? (I can't find
one.)
- Will doing this reduce the size of the .tch graph in any way? Or
does it just remove the workflows from the UI?
- Manually editing the .tch graphs to remove all changes of particular
types, or made before a certain date.
- Is there any easy way of doing this? (I can only think of exporting
the graphs, editing them in TBC or a text editor, and then re-importing
them.)
It would be nice if there were a built-in setting to "only keep the last x
years of changes in the change history" or something similar. It would also
be nice if there were a way to only "keep forever" a particular type of
change data: who made which edits* to a project* and when. Over the long
term, other types of change data (e.g. details *about workflows *and which
changes they contained) are not useful to us and could be deleted after a
certain period (say, a year).
For example, suppose I start a new workflow for a taxonomy, add 30
altLabels to concepts, send the workflow on to a colleague for review, and
then commit the changes to production. The only data I'd want to know *forever
*by consulting the change history is the date, time, and creator of those
30 edits to altLabels -- not the fact that they were part of a certain
workflow, or the facts that the workflow was
created/transitioned/committed/archived by certain people at certain dates
and times.
Thanks for any insight that either TQ users or team members can provide.
-Carl
--
You received this message because you are subscribed to the Google Groups
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/56722c17-4adc-4816-808f-c1f5869f61e5%40googlegroups.com.
