Thanks, Holger. This is quite helpful. What exactly does archiving an already-committed workflow *do*, other than removing it from the Workflows user interface?
Do you agree that it might be useful to have some of the workflow management functions we are discussing available to admins via a UI in EDG? I am considering opening a feature request ticket for those. -Carl On Monday, September 9, 2019 at 1:46:36 PM UTC-7, [email protected] wrote: > > 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 > On Monday, September 9, 2019 at 1:46:36 PM UTC-7, [email protected] wrote: > > 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/524eccb6-7190-4889-bf74-3c250b056206%40googlegroups.com.
