Which elements changed?

[Paolo F Cantoni]

As some of you may know, we run an automatic diagrammer across our entire repository every night to update what are known as Neighborhood diagrams for each element in the repository.

However, even at the rate of processing thousands of diagrams per hour, with the ever increasing number of items in the repository, we aren't able to process all the elements in the repository in the required time frame (that is, before work starts again in the morning).  (Even with the much faster build 909 processing! - with builds after 909, forget it!)

Anyway, we need to work smarter, not harder.  We need to figure out which items changed and ONLY update their diagrams.

Since EA is deficient in footprinting (I'm not anticipating using Auditing at this stage for performance, and other reasons, reasons), I need an algorithm to determine which elements have changed to require a re-rendering of their neighborhood.

Assuming a mechanism for recording last “full repository” scan.  Time of start and completion of last scan, recoding of last Package ID, Element ID, Connector ID, Attribute ID, Operation ID (most in absence of time footprints)  At start and at end of scan.

• List of relevant  elements whose Creation Timepoint > Start of last scan or Last Modified Timepoint > End of last scan
• List of relevant  elements in packages created/modified since start of last scan – needs check to see of adding diagram adjusts – so maybe since end of last scan
• List of relevant  elements in non-autoupdateable diagrams created/modified since start of last scan
• List of relevant  elements with attributes created (ID > recorded) since start of last scan
• List of relevant  elements with operations created (ID > recorded) since start of last scan
• List of elements at either end of connectors created since the last scan.

A select distinct on this set should give me the lists of elements to process..

Any other tests I could/should  do?

TIA,
Paolo

[Uffe]

I don't think that modifying a composite diagram causes the element's modification timestamp to change, so that might be a worthwhile check.

And just out of left field, but it should be pretty easy to write your own audit logger as an Add-In which catches EA_OnPostNew* and EA_OnNotifyContextItemModified, and logs to a custom server or to the Windows logger. I'm not sure whether you could catch all relevant model changes that way, however.

/Uffe

[Paolo F Cantoni]

I don't think that modifying a composite diagram causes the element's modification timestamp to change, so that might be a worthwhile check.

And just out of left field, but it should be pretty easy to write your own audit logger as an Add-In which catches EA_OnPostNew* and EA_OnNotifyContextItemModified, and logs to a custom server or to the Windows logger. I'm not sure whether you could catch all relevant model changes that way, however.

/Uffe

Thanks for that Uffe.  

With regards to Audit, I'm not really interested in a transactional solution at this stage, but a more declarative one.

If EA had proper footprinting, then I wouldn't be asking the question.

Paolo