1

erwartete ich die folgende Abfrage in meiner AnwendungNDB-Query-Erstellung funktioniert nicht wie

query = cls.query().filter(cls.taskgroup_id == taskgroup_id, cls.availability == True, cls.task_id > min_task_id).order(cls.task_id) query.fetch(1)

Above funktioniert wie erwartet haben. (Ruft nur die Entitäten ab, die taskgroup_id entsprechen und verfügbar sind, und task_id> min_task_id)

Allerdings, wenn ich die Abfrage in mehrere Anweisungen aufspalte.

query = cls.query() 
query.filter(cls.taskgroup_id == taskgroup_id) 
query.filter(cls.availability == True) 
query.filter(cls.task_id > min_task_id) 

Es funktioniert nicht wie erwartet.

Wenn ich [2] ausführen, Abfrage Formation in mehrere Anweisungen aufgeteilt, gibt es mir eine Entität, deren Verfügbarkeit ist False, und task_id ist gleich min_task_id.

[2] funktioniert nicht wie erwartet (oder wie ich es erwarte). Ich denke, hier ist ein Benutzerfehler. Frage mich, was es ist.

Antwort

2

Von Filtering by Property Values (Hervorhebung von mir):

query = Account.query(Account.userid >= 40, Account.userid < 50) 

[...]

Anstatt einen gesamten Abfragefilter in einem einzigen Ausdruck spezifiziert, Sie finden es bequemer zu bauen es bis in den Schritten: zum Beispiel:

appengine/standard/ndb/queries/snippets.py

query1 = Account.query() # Retrieve all Account entitites 
query2 = query1.filter(Account.userid >= 40) # Filter on userid >= 40 
query3 = query2.filter(Account.userid < 50) # Filter on userid < 50 too 

query3 entspricht der query Variablen aus dem vorherigen Beispiel. Beachten Sie, dass Objekte abfragen, sind unveränderlich, so dass der Bau von query2 nicht query1 beeinflussen und den Bau von query3 hat keinen Einfluss auf query1 oder query2.

Mit anderen Worten, für Ihr Beispiel ändert keine der query.filter() Anweisungen tatsächlich query.

Ordnen Sie die Ergebnisse der Anweisungen den lokalen Variablen zu und verwenden Sie diese stattdessen, genau wie im Beispiel.

+0

Interessant. Wusste nicht, dass Abfrageobjekte unveränderlich waren. Ich frage mich, was das dahintersteckt. Das Zuweisen von Ergebnissen zu temporären Variablen (obwohl das Problem gelöst wird) macht es meiner Meinung nach hässlich (ich könnte falsch liegen, und es gibt einen guten Grund, das zu tun, denke ich). – user462455

+0

Zum einen gibt es die Möglichkeit, eine oder mehrere verwandte Abfragen mit einem oder mehreren Filtern, die bedingt hinzugefügt wurden, zu konstruieren (zum Beispiel Filter konfigurierbar und auswählbar durch den Benutzer über GUI). Wenn die Abfrage nicht unveränderbar wäre, müssten Abfragen von Grund auf überall in einer potentiell komplexen Bedingungslogik erstellt werden - nicht-DRY und IMHO mit höherer Fehleranfälligkeit. –

+0

Interessant. Ich dachte, dass die Empfehlung, temporäre Variablen zu erstellen, wegen der Unveränderlichkeit genauso fehleranfällig ist. Es ist sehr üblich, Bugs zu sehen, in denen query1 statt query2 (query3 = query1.filter (*) statt query2.filter (*) verwendet wird. Und da es sich um einen logischen Fehler handelt, dauert das Debuggen länger als erwartet.Wäre besser, wenn sie ein veränderbares Abfrageobjekt bereitstellen, so wie Java StringBuilder (veränderbar) zusammen mit String (unveränderlich) bereitstellt. – user462455