2017-10-19 1 views
0

Ich kann den Gültigkeitsbereich bestimmter Tabellen nicht auf publicOnServer setzen. In meiner model.js habe ich den Spielraum für die Tabelle festgelegt. Die Änderung im Umfang kann gesehen werden, wenn ich mein Remote-Modell (4D-Datenbank) in Wakanda- den Bereich der Tabelle nach meiner Änderung aktualisiert.Wakanda 2.x kann den Gültigkeitsbereich bestimmter Tabellen nicht auf publicOnServer setzen

Mit einigen Tabellen, wenn ich den Bereich festlegen und dann irgendeine Art von Abfrage von der Clientseite - zu jeder Tabelle - die Konsole in meinem Browser füllt sich mit Fehlern und die Abfrage schlägt fehl. Wenn Sie den Gültigkeitsbereich bestimmter Tabellen in model.js festlegen, wird die Abfrage sogar für eine Tabelle ohne Bezug unterbrochen.

Ein Unterschied, den ich zwischen den Tabellen feststellen, für die Bereichsänderungen funktionieren, und denen, wo es nicht Tabellen mit relationalen Attributen gibt. Wenn Sie den Gültigkeitsbereich für diese Tabellen festlegen, wird die Abfragefunktionalität durchbrochen, und der Einstellungsbereich für Tabellen ohne relationale Attribute funktioniert durchgängig gut. Ist das ein Fehler?

Chrome Konsolenausgabe: ERROR Error: Uncaught (in promise): Error: Needed Contractor dataClass is not present on catalog

Linie in model.js: model.Contractor.properties.scope="publicOnServer";

Auftragnehmer ist eine Tabelle, in der Remote-Modell und verfügt über relationale Attribute.

Antwort

1

Ich lief die Lösung und basierend auf dem Modell Ihres Projekts. Dies ist ein Standardverhalten und der Fehler wird erwartet. Jede Datenklasse, die auf "PublicOnServer" festgelegt ist, wird vom Client als "entfernt" oder "verborgen" betrachtet. Das Beziehungsattribut in einer anderen Klasse, die auf diese Klasse verweist, wird als Fehler betrachtet, genauso wie es auf eine nicht existierende Klasse verweist. Der Fehler wird nicht angezeigt, wenn die Books-Klasse auf "PublicOnServer" festgelegt ist, da sie nicht mit einer anderen Klasse verknüpft ist.

Wenn Sie die erste Zeile in dem Fehler-Stack klicken: wakanda-client.no-promise.js Zeile: 1880. Sie werden den folgenden Code finden:

//Check if we have all needed dataClasses on the catalog 
for (var _e = 0, _f = _this.seenDataClasses; _e < _f.length; _e++) { 
    var dcName = _f[_e]; 
    if (!catalog[dcName]) { 
     throw new Error('Needed ' + dcName + ' dataClass is not present on catalog'); 
    } 
} 

in Zeile 1775 erhalten Sie eine Funktion finden needdataClass() vergleicht das Array seenDataClasses mit Datenklassen.

Wakada Client-Framework überprüft in der Tat sofort alle öffentlichen Datenklassen und prüft, ob sie relationale Attribute haben, die auf eine nicht öffentliche Datenklasse verweisen. Dies wird zukünftige Probleme in nachfolgenden Abfragen vermeiden.

Der Fehler "Fehler in der Konsole verschwinden, wenn die Lösung gestartet wird, ohne den Zugriff auf die Unternehmenstabelle einzuschränken." wird vom Wakanda-Client hinzugefügt, um zu verhindern, dass Sie die Client-Tabelle mit einem ungültigen Beziehungsattribut abfragen.

wakanda.getCatalog() 
    .then((ds) => { 
     this.ds = ds; 
    }).catch(error=>{ 
     //handle the error 
}); 

Zurück Antwort:

In meinem Verständnis, wenn die dazugehörige Tabelle der Tabelle Sie abfragen wird als „publicOnServer empfehle ich einen Haken Hinzufügen() in Ihrem Code, es zu handhaben "Die Abfrage funktioniert so lange, wie die zugehörige Tabelle in der Abfragezeichenfolge oder in den Abfrageergebnissen nicht referenziert wird.

Können Sie ein reproduzierbares Beispiel für Ihr Modell und Code, der die Abfragezeichenfolge enthält, bereitstellen?

+0

Ja- Link unten. Eigentlich bringt nur der Wakanda-Katalog den Fehler. Muss nicht einmal abfragen. https://www.dropbox.com/s/85pr5svswpi6m07/TableScope.zip?dl = 0 – NAMS

+0

Ich verstehe, danke. Dieses Verhalten unterscheidet sich von Wakanda 1.x, weshalb ich überrascht war. Ich dachte an eine Problemumgehung, bei der ich alle Tabellen öffentlich machen und die restric (etc) Methoden für alle Tabellen entsprechend schreiben werde. – NAMS

+0

IMO mithilfe von Berechtigungssteuerung und Einschränken der Abfrage möglicherweise die bessere Lösung, wenn mehr als zwei Benutzergruppen mit unterschiedlichen Berechtigungen vorhanden sind. Es gibt eine [2016-Gipfelsitzung zu KB] (http://kb.4d.com/assetid=77627), die das Thema behandelt. Der Großteil der Serverimplementierung würde immer noch in V2 gelten –

Verwandte Themen