On 11/09/2019 02:17, [email protected] wrote:
Thanks, Holger. This is quite helpful.
What exactly does archiving an already-committed workflow /do/, other
than removing it from the Workflows user interface?
Archiving removes the metadata about which triples were added or deleted
from the TCH graph. As a result it becomes later impossible to track the
origin of those triples (if that's of interest), yet it leads to
significantly smaller footprint in the database.
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.
Yes I would encourage you to file a ticket so that we can discuss
specific ideas. I assume a feature to archive all committed working
copies (up to a certain date?) would be useful, if it's not already
exposed through the UI somewhere.
Holger
-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:
o 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.)
o 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.
o 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:
o 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.)
o 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.
o 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]
<mailto:[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
<https://groups.google.com/d/msgid/topbraid-users/524eccb6-7190-4889-bf74-3c250b056206%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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/7c49e375-cbf4-ce3b-945e-2daf69d282f0%40topquadrant.com.
