Refactor met.process and dbfiles

[Sweetdevil144]

Description

• Optimized the standardization process by combining the two loops and improving efficiency.
• Added return statement where we intended to return but didn't implement

Motivation and Context

Removed the redundant loop that iterated over standardize_result to update ready.id. Instead, ready.id is now directly assigned the values from the current iteration's standardize_result if is_standardized is TRUE every time we perform a standardization.

For now, I've commented out the previous changes and will remove them once the current changes are approved.

Review Time Estimate

• Immediately
• Within one week
• When possible

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation.
• My name is in the list of CITATION.cff
• I have updated the CHANGELOG.md.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[infotroph]

I think this changes behavior: previously ready.id would have an entry for each id whether it was standardized or not; this only adds the ids that were standardized. Is that intentional?

(As currently implemented I think ids not standardized would probably have errored out earlier, but this step should not rely on that)

[Sweetdevil144]

I've implemented a NA appending too to make sure to append even when we have face a !is_standardized condition. The initial though process I had was whether it would be wise pass the input.id's to .met2model.module and later on to convert_input if we have not standardised our results. Although it seems I failed and ignored the order in array at check which may change the results.

[Sweetdevil144]

@infotroph Can you take a look into this?

[infotroph]

@Sweetdevil144 I was wrong above about the existing behavior -- In the current code standardize_result has an entry for each id, but it is NULL for ids not standardized and therefore gets silently dropped when appending to ready.id. I don't know how advisable that is, but I bet downstream code relies on it.

I'll suggest changes here that eliminate the second for-loop but keep the original behavior -- please edit further if you see problems I missed.

[infotroph]

@Sweetdevil144 I was wrong above about the existing behavior -- In the current code standardize_result has an entry for each id, but it is NULL for ids not standardized and therefore gets silently dropped when appending to ready.id. I don't know how advisable that is, but I bet downstream code relies on it.

I'll suggest changes here that eliminate the second for-loop but keep the original behavior -- please edit further if you see problems I missed.

[Sweetdevil144]

I think this PR is ready for review. Mentioning @infotroph and @moki1202 for approval