How to store.createRecord().save() without immediately effecting the client side instance?

Ember Data
1

Ember store.createRecord() insert the record immediately into store. It have huge problem when the record is a Real-time shared table on the server , IE , real-time / chat/ shared document. the long running EventSource/Websocket is updating the store in behind when new data is arrived, so it is not necessary for createRecord/DeleteRecord/updateRecord to effect immediately at local store. When multi-users are chatting , it screwed the ordering and sync.

Any way to make it so create/delete/update do not effect client-side data store , unless pushed by long running service ? while using createRecord/deleteRecord/updateRecord with save ?

2

Not sure I completely understand the question but it sounds like you could just filter out records where isNew is true.

Edit: if you are using .save() then surely you have created the record on the server so I’m not sure why you wouldn’t want it to show? I guess a hack workaround would be to filter out records where the id is greater than X (assuming you have an id available on your records).

3

@ricky1981 I found filtering by isNew is not ok , because it is no longer isNew when ```POST`` is successful. In real-time message queues , the long running service of websocket/EventSource is the one pushing to the client side store. I want to skip pushing data to client store when createRecord() is done.

4

I’ve handled cases like this by using store methods only for data retrieval while calling my api directly for anything I don’t want to update the local store, eg. this.get('ajax').post('https://api.mine.com/my-models', { data: { foo: 'bar' } }) instead of this.store.createRecord('my-model', { foo: 'bar' }).save().

This assumes you’re also using ember ajax and that you’ve injected it, Ember.inject.service('ajax'), in whatever context you need it. Otherwise you can build your own XMLHttpRequest.

1 Like
5

Thanks a lot. But avoding createRecord/and every update functions , actually defeats the purpose of using Emberjs because ember-data is very powerful.

here is my current solution. i think there are much proper ways to do so.