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

[bug] get_row_from_web_id is not always recursive #59

Open
jerometerrier opened this issue Jan 2, 2025 · 1 comment
Open

[bug] get_row_from_web_id is not always recursive #59

jerometerrier opened this issue Jan 2, 2025 · 1 comment

Comments

@jerometerrier
Copy link

When i'm using pi-system-retrieve-list recipe, i have not always the same result.
Sometimes, i'm limited by hided max_count parameter, sometimes not.

If i use "Path" in source path column, everything is working well.
But if i use "Webid" in source path column, recursive call are not implemented, so i just have the first 1000 values.

@alexbourret
Copy link
Contributor

Hi @jerometerrier !
Thank you for your many contributions ! This is a quick review of what was done on our side:

  • PR 60 was merged as is
  • PR 57 could not be merged directly. The reasons are that:
    • it would break existing flows, because for the recipe.py to work the UI requires context_columns defined, which is not true as long as all the existing occurences of the recipe have been re-saved by the user
    • as it stand, the recipe requires at least one context column to be defined
      Also, we realise the need for contextual information in most instance, which is why, by default, new custom recipes should at least copy all columns from the input dataset in the output. With this in mind, we think it make more sense to add a Copy input parameters boolean in the UI which allows to either
      • keep the previous behaviour to avoid breaking existing flows with schema changes
      • use the new approach and copy all input columns in the output
  • PR 54 was merged as is

You can test the latest beta of the plugin here (v1.2.4-beta.4). Please let us know if the alternative approach for PR 57 is acceptable to you, as well as if you see any other unsolved issue.
Best Regards,
Alex

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants