What if you want to see all files, created for the whole of 2021?
Most likely, you'll create the following request,
GET /api/domain/odata/Systems_Core_ObjectFiles?$filter=Object/CreationTimeUtc%20ge%202021-01-01T00:00:00.000Z%20and%20Object/CreationTimeUtc%20le%202021-12-31T00:00:00.000Z HTTP/1.1
Host: demodb.my.erp.net
I.e., get all files, created between 01.01.2021 and 31.12.2021.
OK, and the result will be exactly what you expect. But.. there's one very important detail.
What if the request from above returns, for example, 1000 files. And what about their content (e.g., an average of 0.5MB per file)? Such a response will be about 500MB size!
This is where the delay-loaded attributes come into play. Their name suggests what they will do. They will be DELAYED.
In this particular case the EmbeddedFileContents attribute is delay-loaded.
In other words, it won't be included in the response until it's explicitly included in the select clause.
Why this is considered a breaking change?
Because all delay-loaded attributes aren't included in the DEFAULT select clause. E.g. if you make requests like these,
~/Systems_Core_ObjectFiles?$top=10
~/Systems_Core_ObjectFiles?$top=10&$select=DEFAULT
~/Systems_Core_ObjectFiles?$top=10&$select=*
The returned entities (if any), won't include the EmbeddedFileContents attribute. Because it's delay-loaded and you have to specify it explicitly.
~/Systems_Core_ObjectFiles?$top=10&$select=DEFAULT,EmbeddedFileContents
Remarks
The examples from above were given in the context of the EmbeddedFileContents delay-loaded attribute, part of the ObjectFiles entity.
The delay-loaded attributes are a separate attributes' category and they don't depend on a specific entity.
0 Comments