Caché Upgrade Checklists - InterSystems Documentation

Caché 2011.1 Upgrade Checklistany Caché server from 2010.1 and later. This file affects all clients connecting to the server, not the clients working oncurrent machine.Note:The default configuration file now uses a LAZY fetch policy and a GENERATE_HELPERS access method. Thisrequires third-party open source libraries (available under Apache license). If this is not acceptable to a specificsite, the configuration file MUST be changed.3.2.7.3 Changes To Java Generated Code For PropertiesBecause of the new object dispatch Java driver in 2010.1 and beyond no longer uses projected values fields ii_, jj_, or kk_. Generated samples will need to have the CacheDB.jar from 2010.1or later in order to work properly.3.2.7.4 Class Name Changes For Caché eXtremeThis change renames the Java package for eXTreme dynamic objects, previously com.intersys.extreme, to com.intersys.xdo(where “xdo” is an acronym for “eXTreme Dynamic Objects”, analogous to “xep” for “eXTreme Event Persistence”).The classes within this package are renamed as follows:Fromcom.intersys.extreme.XTDatabaseConnectioncom.intersys.extreme.XTDatabaseConnectionFactorycom.intersys.extreme.XTDynamicObjectcom.intersys.extreme.XTExceptioncom.intersys.extreme.XTNullValueExceptionTocom.intersys.xdo.DatabaseConnectioncom.intersys.xdo.DatabaseConnectionFactorycom.intersys.xdo.DynamicObjectcom.intersys.xdo.XDOExceptioncom.intersys.xdo.XDONullValueExceptionThe sample code java/samples/extreme/extreme/XTDemo.java has been changed to java/samples/extreme/xdo/XDODemo.java.3.2.7.5 Change To Object Save Methodology In JalapeñoWith this version, if the fetch policy is DISCARD_AFTER_FETCH, and a list of related objects have been never accessedby the application from the parent side, then Jalapeño does not check to see if the objects in this list have been modifiedeven on deep save. This drastically improves performance of deep saving a set of objects with a complex relationship graph.However, there is a possible loss of data when the fetch policy is DISCARD_AFTER_FETCH in the following scenario:• Fetch an object (object A) from the database.• Make some changes to it and objects that it references.• Keep a referenced object (object B) in the application heap memory.• Save object A back using deep save to save changes in all related objects.• Fetch object A back.• Make some changes to object B using its in-memory heap reference.• Save object A using deep save.In this scenario, the modifications to object B might be not saved! Under these conditions, if application expects implicitmodifications of objects in the application context after they are saved to be noted, it must not use fetch policy DIS-CARD_AFTER_FETCH. It should use the policy REFETCH_AFTER_FETCH.58 Caché Upgrade Checklists