![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Managing link history Topic Summary: Created On: 11-Jun-2004 08:23 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I think it is generally accepted that link management in DOORS is a weakness. At least, it is giving me a lot of headaches. I saw many threads on this, but now I want to ventilate an idea to see what you think of the feasibility.
Use a trigger that acts on module close or module save. Code tests a) has the module been changed? and b) does it contain outgoing links. Then call a routine that updates a LinkStore attribute containing all link reference data. This will of course increase time to shut down a module, as a module containing thousands of links can take 10 or more minutes to update the link store, as you have to loop thru all objects containing outgoing links. The advantage is that you will know who changed a link in what session/date. Another option may be to detect when an object is changed, then test if it contains outgoing links, and update the link store if necessary. This could be the preferred option, but could also induce performance issues. As we have not worked with triggers yet, I wanted to test the water firts before plunging in. What do you think? ------------------------- Pieter de Waard www.nhindustries.com Edited: 11-Jun-2004 at 10:59 by Pieter DE WAARD |
|
![]() |
|
![]() |
|
There is no good solution.
Attr-Save triggers won't work since there is no attribute being modified. Obj-Open triggers won't work since the object is not "opened" when creating a link. Mod-Save triggers don't exist; you'll have to use a Pre-Mod-Close trigger and figure out if it was modified this session. Triggers are not for the feint of heart. Very difficult to write and debug. Be sure the "install trigger" DXL has the option of removing the trigger, along with the option to install it. Put some "print "Hello from TrigCheckLinks\n"" debug statement at the top, along with the module name or object number. Doesn't look good. I'd be tempted to write some DXL to run at night and log all existing or new links. You wouldn't catch it if a link was created and deleted on the same day; oh-well. Storing a string representation of each link in some configuration file is realistic. - Louie |
|
![]() |
|
![]() |
|
Thanks Louie for your insights. Will save a lot more headaches on my part.
What do you mean by "Storing a string representation of each link in some configuration file is realistic." ? What is a configuration file? Pardon my ignorance ... The update-by-night option is on my mind since a long time, hence some other postings from me on the subject of running in batch mode. Haven't got to try it yet, though. ------------------------- Pieter de Waard www.nhindustries.com Edited: 11-Jun-2004 at 22:21 by Pieter DE WAARD |
|
![]() |
|
![]() |
|
Louie,
In the mean time I found your reply to another posting on the issue of conf files, where you describe where they are located on the server and how they work. Can you elaborate a bit more on what you can use them for? If I'm not going to find a solution to this %#$@&^%%$ link history problem, I might be drunk when I post on this forum .... :-) (see Louie's reply to posting in other forum on object numbers). ------------------------- Pieter de Waard www.nhindustries.com |
|
![]() |
|
![]() |
|
Don't think I can post all about the Config files; you'll have to practise on your local DB (got one isntalled on your C drive, no?).
If you are running nightly to keep track of your link history you'll need to store the information somewhere. It occurs to me the over-all algorithm would look like this: [] Write program that stores "links look like this right now in the Project" somewhere. [] Run this program, store results in Temp [] Compare Temp to last week's results. Store the Differrences in the running log file. [] Store Temp permanantly for next week. An option to store the results for next week is in the module itself; perhaps in some "CapturedLinkInfo" Text attribute, where each object stores its own outlinks. Another is to store them in the file system somewhere, and I suggested Config files is an option. But then there is no particular reason no to store them on your C drive. There is no particular methodological reason to use a Config file except that it is available to all users that have acces to that DOORS. The Attribute method seems best to me so long as getting full write access and being able to EDIT at will is allowed. - Louie |
|
![]() |
|
![]() |
|
You could also consider using attribute DXL, with the generate history tagged on the attribute. However this will update at a later date rather then at save point.
------------------------- Graham Stradling, Alcatel-Lucent. |
|
![]() |
Telelogic DOORS
» General Discussion
»
Managing link history
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.