How to `exclude` fields from `fetch` result


In a v7.2 application, type ServicePoint has

earliestBoxxDate: datetime calc "earliest(measurements.(origin == 'BOXX').data.start)"

The stored keyword was intentionally removed[1], but now the following command:

ServicePoint.fetch({filter: Filter.exists('measurements.(origin=="BOXX")'), limit: 1, include: 'earliestBoxxDate'}).objs[0].measurements

returns all the fields used to calculate earliestBoxxDate (including measurements as above), none of which are needed in the result. In particular, measurements take a lot of memory, and we would like to exclude them to avoid running out of memory in production.

Is there any way to avoid returning non-included fields?
Some annotation perhaps?
Was such a feature added in a later version?


[1] It was an example of bad design because each new measurement loaded caused field recalculation, including CalcFieldQueue entry merges. In general, do not use stored calc when the field depends on a timeseries; use just calc instead.


@AlexBakic I think what we want to do is to make non-stored calc fields only returned when specifically requested (or another non-stored calc that depends on it is requested). We probably should have done that now. Please file a ticket for that. It might be a bit dangerous though if any code is depending on the current behavior. I’ll discuss with @DavidT to see if we can do it across the board, or at least have an opt in on the type/field in question.


@trothwein I may be wrong/confused but I think Alex’s issue is not so much that the calc field itself is returned (he actually asked for it), but that all the “ingredients” that went into it are included as well. In this case, he does want earliestBoxxDate but he doesn’t want its inclusion to also imply inclusion of measurements.


Yes, the calc field is returned correctly, but we would like to exclude some other fields.


Ah, I misunderstood. We don’t have that feature yet.


I should have added that I wanted undefined as the result above (for measurement field) to make it clearer.
We will have to survive on v7.2 in prod like this until the migration to v7.8, but then it may remain a problem if the objects are not gc’d quickly. Can we request this feature?


File a ticket; roadmapping/prioritization is not done through this website :slight_smile: