2017-10-19 10 views
0

特定のテーブルのスコープをpublicOnServerに設定できません。私のmodel.jsでは、テーブルのスコープを設定しました。スコープの変更は、ワカンダでリモートモデル(4Dデータベース)を表示したときに表示されます。変更後にテーブルのスコープが更新されます。Wakanda 2.xは特定のテーブルのスコープをpublicOnServerに設定できません

一部のテーブルでは、スコープを設定してクライアント側から任意のテーブルに任意の種類のクエリを実行すると、ブラウザのコンソールにエラーが表示され、クエリが失敗します。効果的には、model.js内の特定のテーブルのスコープを設定すると、無関係なテーブルであってもクエリが中断されます。

1つの違い私は、スコープの変更が機能するテーブルと、それがリレーショナル属性を持つテーブルではないテーブルとの間に気づいています。これらのテーブルのスコープを設定すると、クエリ機能が一貫して機能しなくなり、リレーショナル属性のないテーブルの設定スコープが正常に機能します。これはバグですか?

クロームコンソール出力: model.jsでERROR Error: Uncaught (in promise): Error: Needed Contractor dataClass is not present on catalog

ライン: model.Contractor.properties.scope="publicOnServer";

契約者は、リモート・モデル内のテーブルであり、リレーショナル属性があります。

答えて

1

解決策を実行し、プロジェクトのモデルに基づいています。これは標準的な動作であり、エラーが予想されます。 "PublicOnServer"に設定されているデータクラスは、クライアント側から "削除"または "非表示"とみなされます。このクラスを参照している他のクラスのリレーション属性は、存在しないクラスを参照しているようにエラーとみなされます。 Booksクラスが他のクラスに関連していないため、 "PublicOnServer"に設定されている場合、エラーは表示されません。

エラー・スタック内の最初の行をクリックした場合:wakanda-client.no-promise.jsライン:1880年には、次のコード見つける:ライン1775で

//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'); 
    } 
} 

をあなたは機能がありますデータクラスに必要な、seenDataClassesという配列を比較する、RequiredDataClass()。

実際には、Wakadaクライアントフレームワークはすべてのパブリックデータクラスを即座にチェックし、非パブリックデータクラスを参照するリレーショナル属性を持つかどうかを調べます。これにより、後続の問合せでの将来の問題を回避できます。

エラー "ソリューションがCompanyテーブルへのアクセスを制限せずに起動された場合にコンソールのエラーが消えます。" Wakandaクライアントによって、無効なリレーション属性を含むClientテーブルのクエリを停止するという約束が追加されました。私はそれを処理するために、あなたのコード内で)(キャッチを追加することをお勧めします:

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

前の回答:私の理解で

、あなたが照会されているテーブルの関連テーブルがpublicOnServer」として設定されています関連するテーブルがクエリ文字列またはクエリ結果で後で参照されない限り、クエリは機能します。

モデルとクエリ文字列を含むコードの再現可能な例を提供できますか?

+0

はい - リンク先実際には、wakandaカタログを取得するだけでエラーが発生します。クエリする必要もありません。 https://www.dropbox.com/s/85pr5svswpi6m07/TableScope.zip?dl = 0 – NAMS

+0

ありがとうございます。この動作はWakanda 1.xと異なり、私は驚いたのです。私はすべてのテーブルを公開し、それに応じてすべてのテーブルの制限(etc)メソッドを記述するという回避策を考えました。 – NAMS

+0

異なる権限を持つユーザーグループが3つ以上ある場合は、アクセス制御とクエリの制限を使用するIMOが優れたソリューションになる可能性があります。それをカバーする[KBに関する2016年のサミットセッション](http://kb.4d.com/assetid=77627)があります。ほとんどのサーバー実装はまだV2に適用されます –

関連する問題