Description
This is:
- [x] a bug report
- We think this is a bug, but if serialization is not explicitly supported/envisioned - it could be considered a feature request
What is the expected behavior?
After loading complex spreadsheets for processing - we serialize the Spreadheet instance and save it in a cache for performance (as the raw load is taking a few seconds depending on the sheet and we are trying to keep the execution time down for a microservice call) - the unserialize is very quick.
What is the current behavior?
This used to work, however when we went from an older version to 1.14.1 the behaviour changed as an instance of Calculation is on the Spreadsheet instance, which when loaded normally from loading a SS file - it populated the private static member on the Calculation class "private static $referenceHelper" in the constructor [ self::$referenceHelper = ReferenceHelper::getInstance(); ].
The problem is that after serialized and then the serialized version is unserialized back into objects - the class instance of Calculation is there inflated on spreadsheet instance - so it uses it - BUT that instance has self::$referenceHelper as null, as serialize does not touch statics and constructors are not invoked for unserialize - the class however assumes the instance has the private static member populated.
This results in a break when a get calculated value call on a cell results in the evaluateDefinedName method being invoked - it breaks on :
"$definedNameValue = self::$referenceHelper->updateFormulaReferencesAnyWorksheet( ..."
In our application we have applied a workaround which checks is_null immediately prior and instantiates it if needed. To keep us moving forward.
What are the steps to reproduce?
- Load a spreadsheet with a named range in a formula on a cell
- Serialize the ss and save out (we do to a cache folder)
- new session
- Load the ss from cached serialized object from file using unserialize
- get calculated value on cell with formula
Which versions of PhpSpreadsheet and PHP are affected?
We noticed it when we moved to 1.14.1 and is still a problem in 1.15.0