Restier pattern for AsNoTracking on get/read

[xsolon]

Is there a pattern to use AsNoTracking on Get requests?

[robertmclaws]

Hello! Great question. Can I ask at which point in the process? Maybe you can send a pseudo code example of what you're trying to accomplish?

Thanks!

[Tiberriver256]

I believe they are referring to this statement in the EFCore documentation:

No-tracking queries are useful when the results are used in a read-only scenario. They're generally quicker to execute because there's no need to set up the change tracking information. If the entities retrieved from the database don't need to be updated, then a no-tracking query should be used.

According to this guidance all OData GET requests should be AsNoTracking for best performance.

[robertmclaws]

Thanks for that @Tiberriver256 it's really interesting. @jspuij what do you think? I would imagine that doing this on the EF6 and EFC6+ side would speed up the results. Maybe it wouldn't be turned on for batches, but for any other GET it makes sense.

[xsolon]

Yeah restier performance takes a dive when getting on an auto populate text search scenario. Similar implementation with aspnetcore odata.does just fine (with asnotracking), but still prefer restier.

…

Sent from my iPhone On May 20, 2023, at 7:01 PM, Robert McLaws ***@***.***> wrote:  Thanks for that @Tiberriver256<https://github.com/Tiberriver256> it's really interesting. @jspuij<https://github.com/jspuij> what do you think? I would imagine that doing this on the EF6 and EFC6+ side would speed up the results. Maybe it wouldn't be turned on for batches, but for any other GET it makes sense. — Reply to this email directly, view it on GitHub<#726 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAMEYT7PRQUY4ZXSMRFZLL3XHFEN5ANCNFSM6AAAAAAYHDKD6Y>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[jspuij]

@robertmclaws. I think it would be a useful addition. There is however another use for tracking. When tracking is on, with recursive queries (e.g expand a parent child relationship on the same entity), the context will detect the same instance and return actually the same entity. Otherwise it will happily recreate the entity from the DB results and you can have two entities pointing to the same record. I'm not sure whether this is relied upon by Restier (e.g. for detecting circular references) or maybe by some users inside the hook functions in their own descendant API. So at least I'd make it configurable. Question is whether we'd make it a global configuration or even more granular.

[xsolon]

Please support AsNoTrackingWithIdentityResolution to address this