Closes #91 length attribute from max data length

[cpiraux]

Thank you for your Pull Request!

We have developed a Pull Request template to aid you and our reviewers. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the xportr codebase remains robust and consistent.

The scope of {xportr}

{xportr}'s scope is to enable R users to write out submission compliant xpt files that can be delivered to a Health Authority or to downstream validation software programs. We see labels, lengths, types, ordering and formats from a dataset specification object (SDTM and ADaM) as being our primary focus. We also see messaging and warnings to users around applying information from the specification file as a primary focus. Please make sure your Pull Request meets this scope of {xportr}. If your Pull Request moves beyond this scope, please get in touch with the {xportr} team on slack or create an issue to discuss.

Please check off each task box as an acknowledgment that you completed the task. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the devel branch until you have checked off each task.

Changes Description

• Add a function argument to get the length either from metadata or data.
• Add a utility function to get the maximum data length per variable, facilitating the automation of metadata length updates.

Task List

• The spirit of xportr is met in your Pull Request
• Place Closes #<insert_issue_number> into the beginning of your Pull Request Title (Use Edit button in top-right if you need to update)
• Summary of changes filled out in the above Changes Description. Can be removed or left blank if changes are minor/self-explanatory.
• Code is formatted according to the tidyverse style guide. Use styler package and functions to style files accordingly.
• Updated relevant unit tests or have written new unit tests. See our Wiki for conventions used in this package.
• Creation/updated relevant roxygen headers and examples. See our Wiki for conventions used in this package.
• Run devtools::document() so all .Rd files in the man folder and the NAMESPACE file in the project root are updated appropriately
• Run pkgdown::build_site() and check that all affected examples are displayed correctly and that all new/updated functions occur on the "Reference" page.
• Update NEWS.md if the changes pertain to a user-facing function (i.e. it has an @export tag) or documentation aimed at users (rather than developers)
• Make sure that the pacakge version in the NEWS.md and DESCRIPTION file is same. Don't worry about updating the version because it will be auto-updated using the vbump.yaml CI.
• Address any updates needed for vignettes and/or templates
• Link the issue Development Panel so that it closes after successful merging.
• Fix merge conflicts
• Pat yourself on the back for a job well done! Much love to your accomplishment!

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (8f5fc66) 100.00% compared to head (98c075f) 100.00%.
Report is 13 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #213   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           14        14           
  Lines          636       664   +28     
=========================================
+ Hits           636       664   +28     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[bms63]

Hi @cpiraux going to have to resolve merge conflicts - a big PR was just merged. Let me know if you need help

[averissimo]

Great job on this ❤️

Some minor comments on parameter assertion

[bms63]

@cpiraux I was missing around with this PR. I noticed that one line had match.args and not match.arg which was causing the R-CMD checks to fail.

Now this new one is showing up. I ran out of time to investigate. Hoping you see the underlying issue!!

[bms63]

@averissimo could you take a look at how we are using match.arg I am not able to get it to work.

@cpiraux I had to put in your argument into the vignettes and update the example for xportr_length() and things are working again!! yay!

Some thoughts:

1. Does xportr_lenght(lenght = "metadata") need to be integrated into xportr_metadata and xportr_write_all() functions? @EeethB something for us to ponder (lets address in separate issue/PR if we think it needs to be updated.)

2. @cpiraux probably shoudl build an example in the documents (function and vignettes) that allows the user to specify length = "data" and show user how it works (let's create separate issue/PR for this one - can you please create the issue)

3. I think the length argument should be re-visited as I found it a bit confusing. Maybe variable_source_length or source_length, length_source?

Okay!! this one is almost to the finish line. Way to go!!

[averissimo]

🤦 I had a typo on the suggestion, sorry about the match.args -> match.args

@bms63 Traced the issue to the "new" order of parameters. vignettes, have variations of the snippet below where they assume that the 3rd element is the verbose instead of metadata.

adsl %>%
  xportr_type(var_spec, "ADSL", "message") %>%
  xportr_length(var_spec, "ADSL", "message")
#...

[bms63]

Suggested change

	#' adsl <- xportr_length(adsl, metadata, domain = "adsl", length = "metadata")
	#' adsl <- xportr_length(adsl, metadata, domain = "adsl", length_source = "metadata")

[bms63]

All these will need to have the argument updated to length_source

[bms63]

wondering if this can be removed since metadata is default??

[bms63]

Very close!! Just need to update where ever length is used to length_source

[bms63]

@cpiraux You are amazing!! Thanks for seeing this one through for us.