Return data instead of void for export node

[QilongTang]

Please Note:

1. Before submitting the PR, please review How to Contribute to Dynamo
2. Dynamo Team will meet 1x a month to review PRs found on Github (Issues will be handled separately)
3. PRs will be reviewed from oldest to newest
4. If a reviewed PR requires changes by the owner, the owner of the PR has 30 days to respond. If the PR has seen no activity by the next session, it will be either closed by the team or depending on its utility will be taken over by someone on the team
5. PRs should use either Dynamo's default PR template or one of these other template options in order to be considered for review.
6. PRs that do not have one of the Dynamo PR templates completely filled out with all declarations satisfied will not be reviewed by the Dynamo team.
7. PRs made to the DynamoRevit repo will need to be cherry-picked into all the DynamoRevit Release branches that Dynamo supports. Contributors will be responsible for cherry-picking their reviewed commits to the other branches after a LGTM label is added to the PR.

Purpose

Return bool instead of void for node OpenXMLExportExcel to indicate of the node has successfully written data into spreadsheet

Declarations

Check these if you believe they are true

• The codebase is in a better state after this PR
• Is documented according to the standards
• The level of testing this PR includes is appropriate
• User facing strings, if any, are extracted into *.resx files
• All tests pass using the self-service CI.
• Snapshot of UI changes, if any.
• Changes to the API follow Semantic Versioning and are documented in the API Changes document.
• This PR modifies some build requirements and the readme is updated

Reviewers

@mmisol

FYIs

(FILL ME IN, Optional) Names of anyone else you wish to be notified of

[mmisol]

Hi @QilongTang . I'm afraid this approach is not compatible with what the Data.ExportToExcel node does. That was my reason for returning void in the first place. Allow me to illustrate with an example.

Starting with this spreadsheet:

And using this graph to only write the "C3" cell:

You can see in the watch node that the Data.ExportToExcel node returns all of the spreadsheet data. However, if I tried this with the Data.OpenXmlExportExcel node I would only get the passed in data, that is 20.

Given the differences in the implementations of the nodes, I don't think there is an easy way to do this, other than doing what the Data.OpenXmlImportExcel node does, but that might be overkill considering the spreadsheet data might no be needed after written and also users can always use the Data.OpenXmlImportExcel node itself if they do need it.

[mjkkirschner]

What about writing a success or failure bool. Void seems like a bad pattern in a data flow language’s library.

…

On May 5, 2021, at 8:50 AM, Martin Misol Monzo ***@***.***> wrote:  @mmisol requested changes on this pull request. Hi @QilongTang . I'm afraid this approach is not compatible with what the Data.ExportToExcel node does. That was my reason for returning void in the first place. Allow me to illustrate with an example. Starting with this spreadsheet: And using this graph to only write the "C3" cell: You can see in the watch node that the Data.ExportToExcel node returns all of the spreadsheet data. However, if I tried this with the Data.OpenXmlExportExcel node I would only get the passed in data, that is 20. Given the differences in the implementations of the nodes, I don't think there is an easy way to do this, other than doing what the Data.OpenXmlImportExcel node does, but that might be overkill considering the spreadsheet data might no be needed after written and also users can always use the Data.OpenXmlImportExcel node itself if they do need it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[QilongTang]

@mmisol @mjkkirschner I can change the implementation so that we always follow up the write request with a read function call so that this node could return all the data. This may not be 100% ideal performance wise but will be purely done for consistency, what do you think?

[mjkkirschner]

@QilongTang can we characterize what the performance cost is?

[mmisol]

@mjkkirschner That would depend on the size of the sheet. If we are dealing with one that is very large, it could take a few extra seconds, plus a chunk of memory. I think returning something like a bool should work too, so if it's more idiomatic for Dynamo I'm fine with that.

[mmisol]

Thanks @QilongTang . This looks good to me

[QilongTang]

Merging since all checks passing