-
Notifications
You must be signed in to change notification settings - Fork 367
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
Update Table.GenerateByPage to handle empty tables being returned #484
base: master
Are you sure you want to change the base?
Conversation
We specifically can't use Table.Combine, as that will effectively break the streaming behavior for most cases. FWIW, we somehow ended up with an older implementation as the "boilerplate" for this function. A slightly newer definition -- albeit one which still doesn't fix the "empty row" problem -- looks like this:
What's better about it is that when you know the table type, it avoids the duplicate request for the first page. |
Thanks for that revised logic! I was planning to look into the effects of the first-row-get-type logic today--but the revision you provided should save me that effort. :-) Is switching from |
Without this change, `try Table.GenerateByPage(each error "bad", type table[A=any])` won't catch the `error "bad"` raised here (which simulates the first data page fetch attempt raising an error).
@CurtHagenlocher, do you like either of the last two commits ("Adjusting error propagation" or "Reverting last change to avoid triggering a row fetch")? |
Per
Table.GenerateByPage
's Helper Functions description, this method should callgetNextPage
until that callback returns null, then will combine all returned pages into a single table.However, when the existing
Table.GenerateByPage
returns an empty table, its actual behavior differs from the above description (see below examples). If the callback returns an empty table,Table.GenerateByPage
may output 0 rows or an extra, all-null row--neither of which seems desirable or in alignment with the above description.This PR addresses these behavior anomalies. (Note: It would be good for someone with internal Power Query knowledge to validate this PR to ensure that it is done in a way that aligns with PQ's lazy paradigm and that it does not trigger extra streaming.)
Demo of Existing's Behavior Anomalies