Data: Cannot free memory via unloadAll('model') if model has relationships

[dknutsen]

So I originally started a discuss thread and I believe @runspired was looking into it, but I wanted to open an issue to track this as it seems it may have fallen off the radar.

Summary

All of this is documented very explicitly in the discuss thread but essentially in our app we load thousands of ember data records and we'd like to unloadAll one or two models from the store to free memory and give the app some more longevity. Unfortunately this doesn't seem possible as the relationships seem to keep the memory around even after the records are unloaded. To actually free the memory we have to unload the entire store, which causes some logic issues.

As mentioned in the discuss thread I made a test app which demonstrates the issue. I've tested with Ember Data 2.10 - 2.12.2 and also 2.13 beta 4. ED 2.12.2 displays the exact behavior described originally and above, while in 2.13 beta 4 the unloadAll method doesn't seem to have any effect at all (it seems broken?).

It may be that, as much of a concern as this memory buildup is to us, that this is intended behavior and will not be changed. If this is the case is there a workaround we could try? Or could we consider adding support for a workaround? Even a dirty hack would be fine, we just need some way to clear out this memory.

[AlfaroLore]

I'm having the same issue, please we need this to be fixed

[Alexander-Krause]

@stefanpenner Any update on this?

[runspired]

Roughly speaking, this isn't a bug. It is; however, an unfortunate side-effect of cleaning up unloadRecord, and is related to the myriad of unloadRecord issues that have been addressed since we landed that clean up.

Calling unloadAll will free up some-memory by culling record instances, unloading some data, and removing any completely-disassociated records (e.g. records with not relationships).

However, it retains empty InternalModel instances for records that do have relationships. This is because we use InternalModel both as resource and resource-identifier in json-api terms. So long as a relationship alerts to us that a resource exists, we must keep an identifier to it.

In the near future we will be bringing support for jsonapi operations including remove, which will allow for users to fully-remove a record from the store. However, even this API is likely not what folks want for this use-case, as remove is for signaling that a deletion has occurred and that a given record should be treated as if it never existed (vs simply not being available locally, e.g. "not loaded").

I suspect that what folks want is for the ability to partition data, either through temporary, discardable store instances or some similar mechanism. That way when they are finished with a partition the entire partition can be released (related records and all). Alternatively the answer might be a mechanism through which to create some records that aren't cached at all. One might imagine the desire to have formalized modeling for the records returned as the result of a query for auto-complete, but not wish for these records to live on beyond the life of the route or the component that utilized them.

In many cases, using inverse: null for relationships is a viable pattern for ensuring that some records are "releasable" or "GC-able" via unloadAll and unloadRecord today in these memory-critical situations.

[igorT]

I believe the amount of memory used will now become much smaller due to record-identifiers work @runspired did. We can now only keep track of foreign keys and don't need to also keep internal models around. @runspired can you verify/close if thats the case please