Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception 'PhpOffice\PhpSpreadsheet\Exception' with message 'Sheet does not exist.' #4192

Closed
xjcallen opened this issue Oct 16, 2024 · 1 comment · Fixed by #4207
Closed

Comments

@xjcallen
Copy link

xjcallen commented Oct 16, 2024

$excel = IOFactory::load("abc.xlsx");
$sheet1 = clone $excel->getSheet(0);
$sheet1->setCellValue('A1','1111111111111');
$excel->addSheet($sheet1);

企业微信截图_20241016200007

@oleibman
Copy link
Collaborator

You need perform your addSheet before setCellValue. (You also need to change the sheet title first; I assume you just omitted that from your code fragment since you would have seen a different error if you didn't do that.)

This is a fairly unusual situation - it will happen only with cloned worksheets. It might be possible to make the PhpSpreadsheet code more resilient; that would add overhead to all setCellValue calls, and lose some functionality (setting quotePrefix attribute correctly) when it is needed. I'll have to think about whether it's worthwhile. In the meantime, you can re-code as above.

@PHPOffice PHPOffice deleted a comment Oct 28, 2024
oleibman added a commit to oleibman/PhpSpreadsheet that referenced this issue Oct 31, 2024
Fix PHPOffice#4192. Although that issue can be dealt with by changing user code, it would be better to fix it within PhpSpreadsheet. A cloned worksheet may have a pointer to a spreadsheet to which it is not attached. Code can assume it does belong to the spreadsheet, and throw an exception when the spreadsheet cannot find the worksheet in question. It may also not throw an exception when it should.

In my comments to the issue, I was concerned that adding in the needed protection would add overhead to an extremely common situation (setting a cell's value) in order to avoid a pretty rare problem. However, there are problems with both the accuracy and efficiency of the existing code, and I think any performance losses caused by the additional checks will be offset by the performance gains and accuracy of the new code.

Spreadsheet `getIndex` attempts to find the index of a worksheet within its spreadsheet collection. It does so by comparing the hash codes of each sheet in its collection with the hash code of the sheet it is looking for. Its major problem problem is performance-related, namely that it recomputes the hash code of the target sheet with each iteration.

A more severe problem is the accuracy of the hash code. It generates this by hashing together the sheet title, the string range of its auto-filter, and a character representation of whether sheet protection is enabled. Title should definitely be part of the calculation (it must be unique for all sheets attached to a spreadsheet), but it is not clear why this subset of the other properties of Worksheet is used. It tries to save some cycles by using a `dirty` property to indicate whether re-hashing is necessary. It sets that property whenever the title changes, or when `setProtection` is called. So, it doesn't set it when auto-filter changes, and you can easily bypass `setProtection` when changing any of the `Protection` properties. Not to mention the many other properties of worksheet that can be changed. Additionally, if you clone a worksheet, the clone and the original will have the same hash code, which can lead to problems:
```php
$clone = clone $original;
$spreadsheet->getSheet($spreadsheet->getIndex($clone))
    ->setCellValue('A1', 100);
```
That code will change the value of A1 in the original, not the clone.

The `hash` property in Worksheet will now be calculated immediately when the object is constructed or cloned or unserialized. It will not be recalculated, and there is no longer a need for the `dirty` property, which is removed. Hash will be generated by spl_object_id, which was designed for this purpose. (So was spl_object_hash, but many online references suggest that \_id performs much better than \_hash.) Our problem example above will now throw an Exception, as it should, rather than changing the wrong cell. `setValueExplicit`, the problem in the original issue, will now test that the worksheet is attached to the spreadsheet before doing any style manipulation. In order that this not be a breaking change, `getHashCode` will continue to return string, but it is deprecated in favor of `getHashInt`, and Worksheet will no longer implement IComparable to facilitate the deprecation.

I had a vague hope that this change might help with issue PHPOffice#641. It doesn't.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

3 participants
@oleibman @xjcallen and others