Site examples not using xportr_df_label()

[rossfarrugia]

@bms63 @elimillera i'm wondering why in all the site examples we show xportr_write("adsl.xpt", label = "Subject-Level Analysis Dataset"), when the xportr_df_label() function exists to write the dataset label out?

Wouldn't these examples be cleaner using the dataset labels direct from metacore$ds_spec rather than needing the user to manually provide these?

[rossfarrugia]

Might be linked with this issue: #180

[EeethB]

Sounds like xportr_df_label() and xportr_write(label = ) do the same thing, but maybe in different ways?

[rossfarrugia]

Sounds like xportr_df_label() and xportr_write(label = ) do the same thing, but maybe in different ways?

Seems one needs manual entry from the user (xportr_write()) and the other (xportr_df_label()) uses the metadata directly from the metacore object. Obviously the latter is preferable to reduce the chance of manual error.

[bms63]

@rossfarrugia We are brainstorming on having xportr_write() take in information from the metatdata for the dataset label. This way the xportr_df_label() function can be dropped from the workflow and take out the manual step from xportr_write().

[rossfarrugia]

@bms63 sorry to add a spanner in works but we would still also have the use case to keep using xportr_df_label() on our side - reason being we write out as a parquet file first with the attributes added and then only create the xpt using xportr_write() separately at the end specifically for eSub purpose. So having the DF label separate to the XPT creation function is useful.

[rossfarrugia]

I do agree with the idea of updating xportr_write() to use the metacore object metadata directly though 👍

[bms63]

I okay so we will keep both then @vedhav something to note

[vedhav]

Thank you for the insightful discussion, It was helpful in understanding the following problems:

1. We have two implementations of setting the dataset label. One in xportr_df_label and another in xportr_write
2. The dataset label is set in the xportr_df_label using metadata which is standard for xportr while we require a non-standard way of setting dataset label using the label argument in the xportr_write
3. Right now, setting the label using xportr_df_label does retain the dataset label state, but it's not clear for the end user because of using a different implementation.

Solution as proposed in this thread:
Use the standard metadata argument in the xportr_write to stay consistent with the other xportr_* functions and depreciate the label argument. Make sure that the dataset label can be set using xportr_df_label or by passing the metadata.

[rossfarrugia]

sounds a plan! and reminder that this issue is probably the most pressing here as its a bug: #180