2012-09-11 13 views
7

ho il seguente modello Emberjs dati:Emberjs dati Come caricare hasMany-Data tardi

App.File = DS.Model.extend({ 
    like: DS.attr('boolean'), 
    comments: DS.hasMany('App.Comment') 
}); 

App.Comment = DS.Model.extend({ 
    file: DS.belongsTo('App.File'), 
    comment: DS.attr('string') 
}); 

E precaricare con:

App.store.load(App.File, {id: 1, like: false}); 

Ora ho pensato, se mi vengono i commenti come questo :

var f = App.store.find(App.File, 1); 
var c = f.get("comments"); 

var c è un EmberArray vuoto e una richiesta viene inviata al server. Ma non ho una richiesta? Perché e come devo farlo? Davvero non voglio precaricare i commenti.

ulteriormente più, se posso aggiungere un commento, ma anche modificare il file simultaneamente:

f.get("comments").createRecord({comment: "test"}); 
f.set("like", true); 
App.store.commit(); 

due richieste vengono inviati al server. Ma se poi restituisco il seguente JSON (per il file):

{ "id": 1, like: true } 

Il mio primo commento visibile scompare di nuovo. Perché? E cosa devo fare?

Grazie per il vostro aiuto!

risposta

1

Per quanto riguarda la prima parte della tua domanda: Si dovrebbe popolare i commenti ids nei dati del file:

App.store.load(App.File, {id: 1, like: false, comments: [1, 2, 3]}); 

Così i commenti saranno caricato in modo pigro quando necessario.

Riguardo alla seconda parte: Non si serializzano di certo gli ID commenti sulla risposta dal server, quindi i commenti vengono reimpostati, come si descrive un elenco di commenti vuoto.

Si dovrebbe almeno restituire i commenti id come mostrato poco prima ... I due problemi sono collegati.

+0

Grazie per la risposta veloce. Ok. Non c'è altro modo? In questo modo si ottengono molto più sql-query per i dati, che nella maggior parte dei casi non sono necessari. E non sarà d'aiuto per il secondo problema, perché la prima richiesta al server è la richiesta di aggiornamento del file. E la seconda richiesta è la richiesta add-comment. Forse funzionerebbe, se aggiungo un secondo commit-command dopo il createRecord. –

+0

Preferirei il meccanismo utilizzato con findQuery. La prima volta che si utilizza l'attributo commenti, una findQuery verrà passata al server. –

+1

Mi sono imbattuto in un problema simile. Sarebbe bello se invece di richiedere gli id ​​per una chiamata findMany, avrebbero supportato il recupero tramite un findQuery utilizzando la chiave esterna. Ho deciso di aggiungere un metodo "getComments" al mio modello che esegue findQuery. – jhorman

0

Sembra che parte della risposta a questo è di utilizzare il metodo DS.Adapter.findAssociation(...) nell'adattatore. Tuttavia, sto avendo lo stesso problema di te quando il record genitore viene caricato di nuovo dal server - tutti i record figlio vengono sottoposti allo zapping.

Ho postato my own question per vedere se riesco a ottenere questo risolto. Se questa domanda viene risposta, probabilmente sarà anche la risposta alla tua.