2013-09-05 10 views
6

Meine Aufzeichnungen sind nicht flach. Sie haben diese Struktur:Eingebettete Datensätze in Glut-Daten 1.0 Beta

{ 
    'type' : 'node', 
    'properties' : { 
     'name' : 'sfddsadfsd', 
     'xxx' : 'sadfdsf', 
    }, 
    'outputs' : { 
     'fghdf' : 'sadfdsf', 
     'xxxx' : 'sdfsd', 
    } 
} 

Sie erhalten die Idee. Diese Felder (properties und outputs) beziehen sich nicht auf sidegeladene Aufzeichnungen; stattdessen sind sie Teil meines Datensatzes (in meiner CouchDb-Datenbank). Ich habe dies getan (bevor ich gelernt habe, dass dies eine Sünde ist, nach Ember-Data-Standards), weil es eine praktische Möglichkeit ist, viele Eigenschaften in einem Dokument zu organisieren - der Begriff, den CouchDb für Datensätze verwendet. Dieser Name legt auch nahe, warum Sie eine Struktur in Ihrem Datensatz haben wollen: weil ein Dokument ziemlich groß werden kann und Sie daher eine Organisationsstruktur benötigen, um Ihr Leben einfacher zu machen (oder zumindest vor dem Anstoßen von Glutendaten).

Ich war glücklich, diese Datensätze mit eingebetteten Eigenschaften mit der vorherigen Version von Ember-Daten zu modellieren. Nun scheint es, dass ember-data dropped support für eingebettete Datensätze hat. Es gibt einen Vorschlag extractSingle der Implementierung und mit mapProperty('id');

Nun einige funky stuff tun: da sie Teil meiner Akte sind, die eingebetteten Eigenschaften/Ausgänge keine Aufzeichnung-ID haben. Es gibt einfach kein Konzept von Eigenschaft oder Ausgabe außerhalb der Knoten. Sie sind keine unabhängigen Daten mit IDs: Sie sind nur Teil des Knotens.

Vorher hatte ich das folgende Modell Definition:

SettingsApp.NodeProperties = DS.Model.extend({ 
    name : DS.attr('string'), 
}); 

DS.RESTAdapter.map('SettingsApp.NodeProperties', { 
    name : {key: 'name'}, 
}); 

SettingsApp.Node = DS.Model.extend(SettingsApp.NodeMixin, { 
    properties : DS.belongsTo('nodeProperties') 
}); 

DS.RESTAdapter.map('SettingsApp.Node', { 
    nodeType: {key: 'type'}, 
    outputs: {embedded: 'always'}, 
    properties: {embedded: 'always'} 
}); 

Was sind meine Möglichkeiten der Modellierung dieser mit glut-Daten 1.0 beta (outputs Teil des NodeMixin ist)? Ich habe keine Ahnung, was ich mit diesen Modellen anfangen soll, und ich habe ungefähr ein Dutzend von ihnen. Es war hart genug, um meine Rekordstruktur in Glut-Daten zu schieben, und jetzt ... Puff, Aufwand weg, es funktioniert einfach nicht mehr.

+0

Wie auf der TRANSITION.md erwähnt: 'Explizite Unterstützung für Embedded-Datensätze für now.' gegangen (https://github.com/emberjs/data/blob/master/TRANSITION.md#embedded-records) Momentan glaube ich nicht, dass Sie eingebettete Datensätze ohne IDs verarbeiten können. Also ja, das ist eine Art Regression im Vergleich zu 0.13. Werfen Sie einen Blick auf diese Diskussion: http://discuss.emberjs.com/t/ember-data-1-0beta-embedded-records/2359/14 – ThomasDurin

+0

Danke. Das scheint nicht sehr ermutigend zu sein :(Weißt du, ob ich mit ember-data 0.13 und der neuesten Version von ember weitermachen kann? Für was ich gelesen habe, ist ember-data 1.0 beta immer noch fehlerhaft und unterliegt wahrscheinlich Änderungen warte auf ember-data 1.0, bevor du diesen riesigen Aufwand durchführst – dangonfast

+0

Sicher kannst du. Ich habe das gleiche Problem (MongoDB-Datenbank) und ich überlege wirklich, in 0.13 zu bleiben, bis eingebettete Datensätze von ember-data richtig gehandhabt werden Es gibt keine Informationen vom Kernteam über dieses Feature, wir wissen nicht einmal, ob dieses Feature Teil von ember data 1.0 sein wird – ThomasDurin

Antwort

5

Wenn Sie nur properties und outputs als rohe JSON-Daten verwenden möchten, können Sie sie als nicht typisierte DS.attr deklarieren, und sie werden unverändert übergeben.

SettingsApp.Node = DS.Model.extend(SettingsApp.NodeMixin, { 
    properties : DS.attr(), 
    outputs : DS.attr() 
});