Well, the findMany is not the Problem! It does already exist and works well! But thats not a query!
When we look for a query we have two performance intensive steps:
- Check which items match the query.
- Get theese items.
generelly problematically for the performance is every network request itself, but also to transfer a big amount of data over the network.
On the server the search for the matching items may also load them into the memory, but its also possible that to load the items would require additional work.
so, if we decide to return only an list of ids, and then create a findMany, its very inefficient when we only return very few items which we already have in the store on the server, since the additional data to transfer over the network are less performance intensive then an additional request!
but when we sent hunderts or thousends of items back, its expensive to load them on the server and we may already have most of them loaded into ember, we should only sent the ids and make the additional findMany request since it is less performance intensive then to load and sent all the items we dont need over the network!
Actually, this decision can only be made by the developer for his individual project and individual model and query!
And, a timer to delete records is never ever a good idea!
May we requre the records for hours, but we absolutly know they wont change in years! Then we have absolutly no reason to delete them!
May we have records that are only valid for seconds, but then we should use websockets or something, or just always reload them when the user loads additional data to always have consistent data!
But most important we dont wont to delete the not up-to-date records!
A delete in current ember way means that the record does not exist anymore on the client and the server! And we still need this state!
We need something new! A way to mark a records as obsolete! So ember does still know the record, but does also know the data are not up to date! So it should update the record next time we need the data, but not immediatly, since we may never need this record again!
As far as I know we dont have this yet, and this is sad! But we need it for both, records and lists!