It appears that the upgrade process overwrites any updates to the symbol scanner customization. Part of the problem caused by this is that there is no easy way to determine what has been scanned for symbols, when, nor how to just rescan for symbols assets without having to go through deep analysis.
Aside from the silent loss of customization, I think it would be very nice if there where clear stages in the analysis queue, with visibility at the file level, as opposed to container scan, with some staging where files could be prevented from progression before they are thrown into the analyze language and loose their current metadata. The current stages for container scan, import, cleanup... are a bit unclear as to their meaning. May be they do what I am asking for..
In any case, it would be nice to have a stage that says "symbol scanning" and a stage after it with something like "entry to structured scanning". Then the administrator could delete the requests from this last stage.
Something like this is pretty much a requirement for any change in the symbol scan workings, either due to changes in the user scanning configuration or by changes in the product internals related to this area.
Do you understand what I am going after ?
This topic has been locked.
3 replies Latest Post - 2013-01-08T23:23:18Z by SystemAdmin
Pinned topic Fix pack upgrade does not preserve symbol scan configuration
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-01-08T23:23:18Z at 2013-01-08T23:23:18Z by SystemAdmin
Re: Fix pack upgrade does not preserve symbol scan configuration2013-01-01T00:40:15Z in response to SystemAdmin>> there is no easy way to determine what has been scanned for symbols
Agree... I can only think of querying the database to see if there are symbols for the file. But that will not tell you what symbol scanning controls (reg.ex parms) were used :-(
>> have a stage that says "symbol scanning"
Currently the symbol scanning is intertwined into container scan, so that would be hard, but... we are discussing making symbol scanner a default deep scanner for files we do not have detailed analyzers, and populating symbols for those languages we do know well from the data provided by those analyzers (ex: literals, comments etc... ).
Re: Fix pack upgrade does not preserve symbol scan configuration2013-01-08T22:54:03Z in response to SystemAdmin>> Currently the symbol scanning is intertwined into container scan, so that would be hard,
IMHO, it is a problem because there can be a ginormous amount of work derived from a (large)container scan. All cross related internally in batches, pending completion posts via REST handshake (if I understand it correctly). Think in terms of a 150K parts container, which is a number I have not made up.
In the old good times, container scan generated requests in the queue for subsequent process. IMHO including hidden work under the container scan was a mistake that should be redesign. Just my opinion.
Re: Fix pack upgrade does not preserve symbol scan configuration2013-01-08T23:23:18Z in response to SystemAdminRight, that is why down the road we are considering making symbol scanner a default deep scanner for files we do not have detailed analyzers, untangling it out from container or classification scan phase.