Symantec Management Platform (SMP) Community

 View Only
Back to Library

Item.Import Implementation Change. 

Feb 16, 2012 06:14 PM

Item.Import Implementation Change

Reasons For the Change

The change was done due to a bug fix. It turned out that in the NS Core platform itself serialization of such basic items as Resources, Management items, Filters was implemented in very inefficient way which cause multiple Save() calls which increased item import time and SQL load.

Also in cases of installation and usage of SaveState()/ RestoreState()  the Save() operation  was called twice which almost doubled the item import time during installation/upgrade.

What was Improved

  1. Solution installation time  - due to the reduced time of resources, management items and filters import and due to reduced logics of saving items implementing the OnSaveState/OnRestoreState mechanism
  2. Items replication time  - particularly filters, resources and management items
  3. Bulk import time of items which are resources, management items and filters. Example: patch data import.

 

What was Done

Sequence of method calls in Item.Import was changed

                Before the fix                                                                 After the fix

Semantics of OnImport has changed.

BEFORE: the fix there was a mess about understanding of what OnImport was supposed to do. It was called after Save() and it was importing some missing Xml elements and then in many cases Save() was called again or some kind of serilaization which intersected with what is done in Save()/OnSave().

NOW: OnImport should import from item Xml into the item object in memory everything what is NOT imported in OnFromXml() and what will be serialized into the DB during the Save() operation.
Everything what is not supposed to be saved each time when an item is being saved should be moved to the OnPostImport() method.
Any kind of serialization in OnImport is risky, because at that point new items do not exist in any SQL tables

Additional exception is thrown in Save() method

It is now explicitly detected whether OnImport() method calls Save(). If yes, an exception is thrown. OnImport should follow its new semantics and not do any kind of serialization.

The two sections above marked with red are compliance conditions – when solutions do not obey them, they are most probably  broken after the fix.

Affected Classes in NS Core:

  • Altiris.NS.ItemMangement.Item.cs
    • Import of security node moved to OnPostIMport()
    • MoveToFolder() moved to OnPostImport
    • Import of the embedded Item nodes moved to OnPostImport()
  • Altiris.NS.ResourceManagement.DataClass
    • Code from OnImport() moved to OnPostImport()
  • Altiris.NS.Replication.ReplicationDataContainer
    • Code from OnImport() moved to OnPostImport()
  • Altiris.NS.Replication.Hierarchy.CoreItemHierarchyRule
    • Code from OnImport() moved to OnPostImport()
  • Altiris.NS.Replication.Hierarchy.UrgentHierarchyRule
    • Code from OnImport() moved to OnPostImport()
  • Altiris.NS.StandardItems.Collection.aseCollection
    •  Code from OnImport() moved to OnPostImport()
  • Altiris.NS.StandardItems.Policies.ClientConfigPolicy
    • Code from OnImport() moved to OnPostImport()
  • Altiris.NS.StandardItems.Product.LanguagePack
    • Code from OnImport() moved to OnPostImport
  • Altiris.NS.StandardItems.SoftwareDelivery.PackageItem
    • Code from OnImport() moved to OnPostImport()
  • Altiris.Resource.resourceTypeItem
    • Code from OnImport() moved to OnPostImport()

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Migration User
Feb 17, 2012 05:27 PM

This is just an absolute joke. Just another example breaking platform contracts.

"BEFORE: the fix there was a mess about understanding of what OnImport was supposed to do. It was called after Save() and it was importing some missing Xml elements and then in many cases Save() was called again or some kind of serilaization which intersected with what is done in Save()/OnSave()."

The behavioural contracts for the last 10 years or so have always been that OnImport is called after Save/OnSave. i.e. When OnImport was called the framework had persisted the item to the db. I dont care if some of your internal Symantec developers misunderstood what the behaviour was supposed to be: you have described the intended purpose/contract here, and it has been the same since 6.0.

Just look at the core changes required to implement this "fix". Do you really think you can roll out a SP that breaks 10+ years of precedence, and not have Solutions break? How do we handle the behavioural differences between different SP levels of the Framework?

Whilst I understand the need to address performance issues (i.e. Somewhere along the line a 2nd save was introduced - probably related to Restore state functionality), this is not the solution.

 

Related Entries and Links

No Related Resource entered.