Answered

How to avoid delegation warning when bulk updating from local collection?

(0) Share

Report

Posted on by MrNappa

241

I'm trying to save a bunch of updates to a (CDS) datasource all at once. To achieve this, I used the following construction:

// 'updates' is a local collection 
ForAll( updates,
 Patch( Elements, LookUp( Elements, ElementId=updates[@ElementId] ),
 {
  // some field updates
 });
);

However, the red part is giving me a delegation warning.

Now I can see where this is coming from: the indexing in the local 'updates' collection is not supported by the LookUp delegation (at least I think that's the cause). However, this is an operation that should not be delegated in the first place: I want it to be performed before going to the data source so it's a simple 'lookup by ID'. But I can't pre-set it in a local variable because the operation takes place within a ForAll.

How can I work around this? Or should I use a different setup alltogether?

(detail: the 'updates' collection is not a 1:1 copy of the 'Elements' data type, but it does contain the ElementId guid)

Categories:

Building Power Apps

I have the same question (0)

All responses (3)

Answers (1)

Verified answer

v-xida-msft Microsoft Employee on at

Like (1)

Report
Copy link

Link copied!
Hi @MrNappa ,

Is the ElementId a GUID type column in your updates collection and the Elements Entity?

How do you initialize the updates collection within your app? Could you please share a bit more about the formula?

I have made a test on my side, please consider take a try with the following formula:

// 'updates' is a local collection ForAll(
RenameColumns(updates, "ElementId", "ElementId1"), Patch(
Elements,
LookUp(Elements, ElementId = ElementId1), { // some field updates }
); );

please take a try with above solution, then check if the issue is solved.

In addition, the amount of your Elements Entity records is not more than 2000, you could ignore this Delegation warning issue. More details about the Delegation in PowerApps, please check the following article:

Delegation

Note: You should set the "Data row limit for Non-delegable queries" option to maximum value -- 2000 within Advanced settings of App settings of your app.

In addition, if the ElementId value stored in your updates collection is a Text value, please modify your above formula as below:

I have made a test on my side, please consider take a try with the following formula: // 'updates' is a local collection ForAll( RenameColumns(updates, "ElementId", "ElementId1"), Patch( Elements, LookUp(Elements, ElementId = GUID(ElementId1)), { // some field updates } ); );

Best regards,

Was this reply helpful? Yes No
MrNappa 241 on at

Like (0)

Report
Copy link

Link copied!

Hi Kris, thanks for the response.

> Is the ElementId a GUID type column in your updates collection and the Elements Entity?
Hm, now that you mention it, there may be some mix up between display name vs schema name. I'd have to recheck it. It should refer to a primary key column.

> How do you initialize the updates collection within your app? Could you please share a bit more about the formula?
It's the filtered contents of a gallery that should contain all entries that the user has not filled out manually.

> I have made a test on my side, please consider take a try with the following formula:
Thanks, I'll see if it improves upon this.

> In addition, the amount of your Elements Entity records is not more than 2000, you could ignore this Delegation warning issue.
I know, however this is a table that will grow over time and this is not something we can ignore. Besides, it's also very inefficient; using the new 'monitor' feature (which is pretty neat, by the way!) I already saw that the query will first load all items from the Elements table and after that apply the filter.

I'll update later with my findings :).

Was this reply helpful? Yes No
MrNappa 241 on at

Like (0)

Report
Copy link

Link copied!
Turns out the ElementId in the lookup was the culprit, after all. This was probably my bad (autocompleting or copypasting the wrong name). The key column in the Elements table was actually called 'Element', and if I used that I could remove the scoping construction "updates[@ElementId]", leading to the correct code:
ForAll( updates, Patch( Elements, LookUp( Elements, Element=ElementId ), { /* updates */ }); );
I think I might essentially have been calling "LookUp( Elements, true )" in a roundabout way...?

ANyway, thanks for the help.

Was this reply helpful? Yes No