Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Hinweise zur Einhaltung von Amazon-Neptune-Standards Amazon Neptune hält bei der Implementierung der Abfragesprachen Gremlin und SPARQL die geltenden Standards meistens ein. Dieser Abschnitt beschreibt die Standards sowie die Bereiche, in denen Neptune-Standards diese erweitern oder von diesen abweichen. **Topics** + [Einhaltung der Gremlin-Standards in Amazon Neptune](access-graph-gremlin-differences.md) + [Einhaltung von SPARQL-Standards in Amazon Neptune](feature-sparql-compliance.md) + [Einhaltung der OpenCypher-Spezifikationen in Amazon Neptune](feature-opencypher-compliance.md) # Einhaltung der Gremlin-Standards in Amazon Neptune Die folgenden Abschnitte bieten einen Überblick über die Neptune-Implementierung von Gremlin und wie sie sich von der Apache-Implementierung unterscheidet. TinkerPop Neptune implementiert einige Gremlin-Schritte nativ in seiner Engine und verwendet die Apache TinkerPop Gremlin-Implementierung, um andere zu verarbeiten (siehe). [Native Unterstützung für Gremlin-Schritte in Amazon Neptune](gremlin-step-support.md) **Anmerkung** Einige Beispiele für diese Implementierungsunterschiede zwischen der Gremlin-Konsole und Amazon Neptune finden Sie im Abschnitt [Verwenden von Gremlin für den Zugriff auf Grafikdaten in Amazon Neptune](get-started-graph-gremlin.md) im Schnellstart. **Topics** + [Geltende Standards für Gremlin](#feature-gremlin-applicable-standards) + [Variablen und Parameter in Skripts](#feature-gremlin-differences-variables) + [TinkerPop Aufzählungen](#feature-gremlin-differences-tinkerpop) + [Java-Code](#feature-gremlin-differences-java) + [Eigenschaften von Elementen](#feature-gremlin-differences-properties-on-elements) + [Skriptausführung](#feature-gremlin-differences-script) + [Sitzungen](#feature-gremlin-differences-sessions) + [Transaktionen](#feature-gremlin-differences-transactions) + [Scheitelpunkt und Kante IDs](#feature-gremlin-differences-vertex-edge-ids) + [Vom Benutzer bereitgestellt IDs](#feature-gremlin-differences-user-supplied-ids) + [Eigenschaft „Scheitelpunkt“ IDs](#feature-gremlin-differences-vertex-property-ids) + [Kardinalität von Eckpunkteigenschaften](#feature-gremlin-differences-vertex-property-cardinality) + [Aktualisieren einer Eckpunkteigenschaft](#feature-gremlin-differences-vertex-property-update) + [Labels](#feature-gremlin-differences-labels) + [Escape-Zeichen](#feature-gremlin-differences-escapes) + [Groovy-Einschränkungen](#feature-gremlin-differences-groovy) + [Serialisierung](#feature-gremlin-differences-serialization) + [Lambda-Schritte](#feature-gremlin-differences-lambda) + [Nicht unterstützte Gremlin-Methoden](#feature-gremlin-differences-unsupported-methods) + [Nicht unterstützte Gremlin-Schritte](#feature-gremlin-differences-unsupported-steps) + [Features von Gremlin-Diagrammen in Neptune](#gremlin-api-reference-features) ## Geltende Standards für Gremlin + Die Gremlin-Sprache wird eher durch die [ TinkerPop Apache-Dokumentation und die TinkerPop Apache-Implementierung](http://tinkerpop.apache.org/docs/current/reference/) von Gremlin als durch eine formale Spezifikation definiert. + Für numerische Formate folgt Gremlin dem Standard IEEE 754 ([IEEE 754-2019 – IEE Standard for Floating-Point Arithmetic](https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html); siehe auch die [Wikipedia-Seite für IEEE 754](https://en.wikipedia.org/wiki/IEEE_754)). ## Variablen und Parameter in Skripts Wenn es sich um bereits gebundene Variablen handelt, ist das Traversierungs-Objekt `g` in Neptune bereits gebunden und das `graph`-Objekt wird nicht unterstützt. Obwohl Neptune weder Gremlin-Variablen noch Parametrisierung in Skripts unterstützt, finden Sie im Internet häufig Beispielskripts für Gremlin Server, die Variablendeklarationen enthalten, zum Beispiel: ``` String query = "x = 1; g.V(x)"; List results = client.submit(query).all().get(); ``` Es gibt auch viele Beispiele, die beim Absenden von Abfragen [Parametrisierung](https://tinkerpop.apache.org/docs/current/reference/#parameterized-scripts) (oder Bindungen) verwenden, zum Beispiel: ``` Map params = new HashMap<>(); params.put("x",1); String query = "g.V(x)"; List results = client.submit(query).all().get(); ``` Die Parameterbeispiele sind in der Regel mit Warnungen vor einer Beeinträchtigung der Leistung verbunden, wenn keine Parametrisierung erfolgt, wenn dies möglich ist. Es gibt eine Menge solcher Beispiele, denen Sie vielleicht begegnen werden TinkerPop , und sie klingen alle ziemlich überzeugend, was die Notwendigkeit der Parametrisierung angeht. Sowohl die Funktion zur Deklaration von Variablen als auch die Parametrisierungsfunktion (zusammen mit den Warnungen) gelten jedoch nur für den Gremlin-Server, TinkerPop wenn dieser den verwendet. `GremlinGroovyScriptEngine` Sie gelten nicht, wenn Gremlin Server die `gremlin-language`-ANTLR-Grammatik von Gremlin verwendet, um Abfragen zu analysieren. Die ANTLR-Grammatik unterstützt weder Variablendeklarationen noch Parametrisierung. Wenn Sie ANTLR verwenden, müssen Sie sich daher keine Sorgen über eine fehlende Parametrisierung machen. Da es sich bei der ANTLR-Grammatik um eine neuere Komponente handelt TinkerPop, spiegeln ältere Inhalte, denen Sie im Internet möglicherweise begegnen, diesen Unterschied im Allgemeinen nicht wider. Neptune verwendet in der Abfrageverarbeitungs-Engine die ANTLR-Grammatik und nicht `GremlinGroovyScriptEngine`. Daher werden Variablen, Parametrisierung oder die Eigenschaft `bindings` nicht unterstützt. Daher sind die Probleme im Zusammenhang mit einer fehlenden Parametrisierung nicht auf Neptune anwendbar. Mit Neptune können Abfragen einfach so gesendet werden, wie sie sind, ohne sie zu parametrisieren. Daher kann das vorherige Beispiel wie folgt vereinfacht werden, ohne dass die Leistung beeinträchtigt wird: ``` String query = "g.V(1)"; List results = client.submit(query).all().get(); ``` ## TinkerPop Aufzählungen Neptune unterstützt keine vollständig qualifizierten Klassennamen für Aufzählungswerte. In Ihrer Groovy-Anforderung müssen Sie beispielsweise `single` anstelle von `org.apache.tinkerpop.gremlin.structure.VertexProperty.Cardinality.single` verwenden. Der Aufzählungstyp wird durch den Parametertyp bestimmt. Die folgende Tabelle zeigt die zulässigen Aufzählungswerte und den zugehörigen TinkerPop vollqualifizierten Namen. | Zulässige Werte | Klasse | | --- |--- | | id, key, label, value | [org.apache.tinkerpop.gremlin.structure.T](https://tinkerpop.apache.org/javadocs/current/core/org/apache/tinkerpop/gremlin/structure/T.html) | | T.id, T.key, T.label, T.value | [org.apache.tinkerpop.gremlin.structure.T](https://tinkerpop.apache.org/javadocs/current/core/org/apache/tinkerpop/gremlin/structure/T.html) | | set, single | [org.apache.tinkerpop.gremlin.structure. VertexProperty. Kardinalität](https://tinkerpop.apache.org/javadocs/current/core/org/apache/tinkerpop/gremlin/structure/VertexProperty.Cardinality.html) | | asc, desc, shuffle | [org.apache.tinkerpop.gremlin.process.traversal.Order](https://tinkerpop.apache.org/javadocs/3.7.2/full/org/apache/tinkerpop/gremlin/process/traversal/Order.html) | | Order.asc, Order.desc, Order.shuffle | [org.apache.tinkerpop.gremlin.process.traversal.Order](https://tinkerpop.apache.org/javadocs/3.7.2/full/org/apache/tinkerpop/gremlin/process/traversal/Order.html) | | global, local | [org.apache.tinkerpop.gremlin.process.traversal.Scope](https://tinkerpop.apache.org/javadocs/3.7.2/core/org/apache/tinkerpop/gremlin/process/traversal/Scope.html) | | Scope.global, Scope.local | [org.apache.tinkerpop.gremlin.process.traversal.Scope](https://tinkerpop.apache.org/javadocs/3.7.2/core/org/apache/tinkerpop/gremlin/process/traversal/Scope.html) | | all, first, last, mixed | [org.apache.tinkerpop.gremlin.process.traversal.Pop](https://tinkerpop.apache.org/javadocs/3.7.2/core/org/apache/tinkerpop/gremlin/process/traversal/Pop.html) | | normSack | [org.apache.tinkerpop.gremlin.process.traversal. SackFunctions. Barriere](https://tinkerpop.apache.org/javadocs/3.7.2/core/org/apache/tinkerpop/gremlin/process/traversal/SackFunctions.Barrier.html) | | addAll, and, assign, div, max, min, minus, mult, or, sum, sumLong | [org.apache.tinkerpop.gremlin.process.traversal.Operator](https://tinkerpop.apache.org/javadocs/3.7.2/core/org/apache/tinkerpop/gremlin/process/traversal/Operator.html) | | keys, values | [org.apache.tinkerpop.gremlin.structure.Column](https://tinkerpop.apache.org/javadocs/3.7.2/core/org/apache/tinkerpop/gremlin/structure/Column.html) | | BOTH, IN, OUT | [org.apache.tinkerpop.gremlin.structure.Direction](https://tinkerpop.apache.org/javadocs/3.7.2/core/org/apache/tinkerpop/gremlin/structure/Direction.html) | | any, none | [org.apache.tinkerpop.gremlin.process.traversal.step. TraversalOptionParent. Wählen](https://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/process/traversal/Pick.html) | ## Java-Code Neptune unterstützt keine Aufrufe von Methoden, die durch beliebige Java- oder Java-Bibliotheksaufrufe definiert wurden, mit Ausnahme von unterstütztem Gremlin. APIs Beispiel: `java.lang.*`, `Date()` und `g.V().tryNext().orElseGet()` sind nicht zulässig. ## Eigenschaften von Elementen Neptune unterstützt das in TinkerPop 3.7.0 eingeführte `materializeProperties` Flag zur Rückgabe von Eigenschaften von Elementen nicht. Infolgedessen gibt Neptune immer noch nur Scheitelpunkte oder Kanten als Referenzen mit nur ihrem UND zurück. `id` `label` ## Skriptausführung Alle Abfragen müssen mit `g`, dem Traversal-Objekt, beginnen. Bei der Übermittlung von Zeichenfolgenabfragen können mehrere Traversierungen ausgegeben werden, durch Semikolon (`;`) oder ein Zeichen für eine neue Zeile (`\n`) getrennt. Alle Anweisungen außer der letzten Anweisung müssen mit einem `.iterate()`-Schritt beendet werden, um ausgeführt zu werden. Es werden nur die Daten der letzten Traversierung zurückgegeben. Beachten Sie, dass dies nicht für ByteCode GLV-Abfragen gilt. ## Sitzungen Sitzungen in Neptune sind auf 10 Minuten Dauer beschränkt. Weitere Informationen finden Sie unter [Skriptbasierte Gremlin-Sitzungen](access-graph-gremlin-sessions.md) und in der [TinkerPopSitzungsreferenz](https://tinkerpop.apache.org/docs/current/reference/#console-sessions). ## Transaktionen Neptune öffnet zu Beginn jeder Gremlin-Traversierung eine neue Transaktion und schließt sie nach dem erfolgreichen Abschluss der Traversierung. Wenn ein Fehler auftritt, wird ein Rollback für die Transaktion durchgeführt. In einer einzelnen Transaktion sind mehrere Anweisungen, die durch Semikolon (`;`) oder Zeilenumbruchzeichen (`\n`) getrennt sind, enthalten. Jede Anweisung, die nicht die letzte Anweisung ist, muss mit einem auszuführenden `next()`-Schritt enden. Es werden nur die Daten der letzten Traversierung zurückgegeben. Eine manuelle Transaktionslogik mit `tx.commit()` und `tx.rollback()` wird nicht unterstützt. **Wichtig** Dies gilt ***nur*** für Methoden, bei denen Sie die Gremlin-Abfrage als ***Textzeichenfolge*** senden (siehe [Gremline-Transaktionen](access-graph-gremlin-transactions.md)). ## Scheitelpunkt und Kante IDs Neptune Gremlin Vertex und Edge IDs müssen vom Typ sein. `String` Diese ID-Zeichenfolgen unterstützen Unicode-Zeichen und dürfen eine Größe von 55 MB nicht überschreiten. Vom Benutzer bereitgestellte Dateien IDs werden unterstützt, sind aber bei normalem Gebrauch optional. Wenn Sie beim Hinzufügen eines Eckpunkts oder einer Kante keine ID angeben, generiert Neptune eine UUID und konvertiert sie in eine Zeichenfolge mit dem folgenden Format: `"48af8178-50ce-971a-fc41-8c9a954cea62"` Sie entsprechen UUIDs nicht dem RFC-Standard. Wenn Sie also einen Standard benötigen, sollten UUIDs Sie sie extern generieren und beim Hinzufügen von Scheitelpunkten oder Kanten angeben. **Anmerkung** Der `Load` Neptune-Befehl erfordert, dass Sie das Feld **\$1id** im Neptune-CSV-Format angeben IDs. ## Vom Benutzer bereitgestellt IDs Vom Benutzer bereitgestellte IDs Dateien sind in Neptune Gremlin mit den folgenden Bestimmungen erlaubt. + IDs Die mitgelieferten Produkte sind optional. + Es werden nur Eckpunkte und Kanten unterstützt. + Es wird nur der `String`-Typ unterstützt. Zum Erstellen eines neuen Vertex mit benutzerdefinierter ID verwenden Sie den `property`-Schritt mit dem `id`-Schlüsselwort `g.addV().property(id, 'customid')`. **Anmerkung** Schließen Sie das `id`-Schlüsselwort nicht in Anführungszeichen ein. Dies bezieht sich auf `T.id`. Jeder Scheitelpunkt IDs muss einzigartig sein, und alle Kanten IDs müssen einzigartig sein. Neptune lässt jedoch zu, dass ein Eckpunkt und eine Kante dieselbe ID haben. Wenn Sie versuchen, einen neuen Vertex mit `g.addV()` zu erstellen und es ist bereits ein Vertex mit dieser ID vorhanden, schlägt die Operation fehl. Dabei gilt die folgende Ausnahme: Wenn Sie eine neue Bezeichnung für den Vertex angeben, ist die Operation erfolgreich, fügt die neue Bezeichnung und alle zusätzlichen angegebenen Eigenschaften aber zum vorhandenen Vertex hinzu. Es wird nichts überschrieben. Es wird kein neuer Vertex erstellt. Die Vertex-ID ändert sich nicht und bleibt eindeutig. Die folgende Gremlin-Konsolenbefehl können beispielsweise erfolgreich ausgeführt werden: ``` gremlin> g.addV('label1').property(id, 'customid') gremlin> g.addV('label2').property(id, 'customid') gremlin> g.V('customid').label() ==>label1::label2 ``` ## Eigenschaft „Scheitelpunkt“ IDs Die Eckpunkteigenschaften IDs werden automatisch generiert und können bei der Abfrage als positive oder negative Zahlen angezeigt werden. ## Kardinalität von Eckpunkteigenschaften Neptune unterstützt Set-Kardinalität und Single-Kardinalität. Wenn die Kardinalität nicht angegeben ist, wird die Set-Kardinalität ausgewählt. Das bedeutet, dass, wenn ein Eigenschaftswert festgelegt wird, ein neuer Wert zur Eigenschaft hinzugefügt wird, sofern dieser nicht bereits im Wertesatz enthalten ist. Dies ist der Gremlin-Aufzählungswert von [Set](https://tinkerpop.apache.org/javadocs/3.7.2/core/org/apache/tinkerpop/gremlin/structure/VertexProperty.Cardinality.html). `List` wird nicht unterstützt. Weitere Informationen zur Kardinalität von Eigenschaften finden Sie im Thema [Scheitelpunkt](https://tinkerpop.apache.org/javadocs/3.7.2/core/org/apache/tinkerpop/gremlin/structure/Vertex.html#property-org.apache.tinkerpop.gremlin.structure.VertexProperty.Cardinality-java.lang.String-V-java.lang.Object...-) im Gremlin. JavaDoc ## Aktualisieren einer Eckpunkteigenschaft Zum Aktualisieren eines Eigenschaftswerts ohne Hinzufügung eines zusätzlichen Werts zum Wertesatz geben Sie die `single`-Kardinalität im `property`-Schritt an. ``` g.V('exampleid01').property(single, 'age', 25) ``` Dadurch werden alle vorhandenen Werte für die Eigenschaft entfernt. ## Labels Neptune unterstützt mehrere Bezeichnungen für einen Eckpunkt. Sie können mehrere Bezeichnungen angeben, indem Sie diese durch `::` trennen. Beispielsweise fügt `g.addV("Label1::Label2::Label3")` einen Knoten mit drei verschiedenen Bezeichnungen hinzu. Der `hasLabel`-Schritt entspricht dem Knoten mit allen drei Bezeichnungen: `hasLabel("Label1")`, `hasLabel("Label2")` und `hasLabel("Label3")`. **Wichtig** Das `::`-Trennzeichen ist dieser Verwendung vorbehalten. Sie können im `hasLabel`-Schritt nicht mehrere Bezeichnungen angeben. Beispiel: Für `hasLabel("Label1::Label2")` gibt es keine Übereinstimmung. ## Escape-Zeichen Neptune löst alle Escape-Zeichen wie im Abschnitt [Escaping Special Characters]( http://groovy-lang.org/syntax.html#_escaping_special_characters) der Apache-Groovy-Dokumentation beschrieben auf. ## Groovy-Einschränkungen Neptune unterstützt keine Groovy-Befehle, die nicht mit `g` beginnen. Dies umfasst mathematische Zeichen (z. B.: `1+1`), Systemaufrufe (z. B: `System.nanoTime()`) und Variablendefinitionen (z. B: `1+1`). **Wichtig** Neptune unterstützt keine vollständig qualifizierten Klassennamen. In Ihrer Groovy-Anforderung müssen Sie beispielsweise `single` anstelle von `org.apache.tinkerpop.gremlin.structure.VertexProperty.Cardinality.single` verwenden. ## Serialisierung Neptune unterstützt die folgenden Serialisierungen basierend auf dem angeforderten MIME-Typ. Neptune stellt alle Serialisierer zur Verfügung, die dies tun, und TinkerPop unterstützt die verschiedenen Versionen und Konfigurationen von GraphSON und. GraphBinary Obwohl es viele Optionen gibt, ist die Anleitung zur Verwendung einfach: + Wenn Sie TinkerPop Apache-Treiber verwenden, bevorzugen Sie die Standardeinstellung für den Treiber, ohne einen explizit anzugeben. Sofern Sie keinen ganz bestimmten Grund dafür haben, müssen Sie den Serializer wahrscheinlich nicht bei der Treiberinitialisierung angeben. Im Allgemeinen ist die Standardeinstellung, die von den Treibern verwendet wird. `application/vnd.graphbinary-v1.0` + Wenn Sie über HTTP eine Verbindung zu Neptune herstellen, sollten Sie der Verwendung von Priorität einräumen, `application/vnd.gremlin-v3.0+json;types=false` da die eingebetteten Typen in der alternativen Version von GraphSon 3 die Arbeit erschweren. + Das `application/vnd.graphbinary-v1.0-stringd` ist im Allgemeinen nur nützlich, wenn es in Verbindung mit der [Gremlin Console](https://docs.aws.amazon.com//neptune/latest/userguide/access-graph-gremlin-console.html) verwendet wird, da es alle Ergebnisse zur einfachen Anzeige in eine Zeichenkettendarstellung konvertiert. + Die übrigen Formate bleiben aus veralteten Gründen weiterhin vorhanden und sollten normalerweise nicht ohne eindeutigen Grund zusammen mit Treibern verwendet werden. | | | | | --- |--- |--- | | MIME-Typ | Serialisierung | Konfiguration | | `application/vnd.gremlin-v1.0+json` | GraphSONMessageSerializerV1 | ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerIoRegistryV1] | | `application/vnd.gremlin-v1.0+json;types=false` | GraphSONUntypedMessageSerializerV1 | ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerIoRegistryV1] | | `application/vnd.gremlin-v2.0+json` | GraphSONMessageSerializerV2 | ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerIoRegistryV2] | | `application/vnd.gremlin-v2.0+json;types=false` | GraphSONUntypedMessageSerializerV2 | ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerIoRegistryV2] | | `application/vnd.gremlin-v3.0+json` | GraphSONMessageSerializerV3 | ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerIoRegistryV3] | | `application/vnd.gremlin-v3.0+json;types=false` | GraphSONUntypedMessageSerializerV3 | ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerIoRegistryV3] | | `application/json` | GraphSONUntypedMessageSerializerV3 | ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerIoRegistryV1] | | `application/vnd.graphbinary-v1.0` | GraphBinaryMessageSerializerV1 | | | `application/vnd.graphbinary-v1.0-stringd` | GraphBinaryMessageSerializerV1 | serializeResultToString: true | | `application/vnd.gremlin-v1.0+json` | GraphSONMessageSerializerGremlinV1 | ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerIoRegistryV1] | | `application/vnd.gremlin-v2.0+json` | GraphSONMessageSerializerV2(funktioniert nur mit WebSockets) | ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerIoRegistryV2] | | `application/vnd.gremlin-v3.0+json` | `GraphSONMessageSerializerV3` | | | `application/json` | GraphSONMessageSerializerV3 | ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerIoRegistryV3] | | `application/vnd.graphbinary-v1.0` | GraphBinaryMessageSerializerV1 | | **Anmerkung** Die hier gezeigte Serializer-Tabelle bezieht sich auf die Benennung ab 3.7.0. TinkerPop [Wenn Sie mehr über diese Änderung erfahren möchten, lesen Sie bitte die TinkerPop Upgrade-Dokumentation.](https://tinkerpop.apache.org/docs/current/upgrade/#_serializer_renaming) Die Unterstützung der Gryo-Serialisierung war in 3.4.3 veraltet und wurde in 3.6.0 offiziell entfernt. Wenn Sie Gryo explizit verwenden oder eine Treiberversion verwenden, die Gryo standardmäßig verwendet, sollten Sie zu Ihrem Treiber wechseln oder ihn aktualisieren. GraphBinary ## Lambda-Schritte Lambda-Schritte werden von Neptune nicht unterstützt. ## Nicht unterstützte Gremlin-Methoden Die folgenden Gremlin-Methoden werden von Neptune nicht unterstützt: + `org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal.program(org.apache.tinkerpop.gremlin.process.computer.VertexProgram)` + `org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal.sideEffect(java.util.function.Consumer)` + `org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal.from(org.apache.tinkerpop.gremlin.structure.Vertex)` + `org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal.to(org.apache.tinkerpop.gremlin.structure.Vertex)` Die folgende Traversierung ist beispielsweise nicht zulässig: `g.V().addE('something').from(__.V().next()).to(__.V().next())`. **Wichtig** Dies gilt ***nur*** für Methoden, bei denen die Gremlin-Abfrage als ***Textzeichenfolge*** gesendet wird. ## Nicht unterstützte Gremlin-Schritte Die folgenden Gremlin-Schritte werden von Neptune nicht unterstützt: + Der Gremlin-Schritt [io( )](http://tinkerpop.apache.org/docs/3.7.2/reference/#io-step) wird von Neptune nur teilweise unterstützt. Er kann in einem Lesekontext verwendet werden, wie in `g.io((url)).read()`, jedoch nicht zum Schreiben. ## Features von Gremlin-Diagrammen in Neptune Die Neptune-Implementierung von Gremlin legt das `graph`-Objekt nicht offen. Die folgenden Tabellen listen Gremlin-Features auf und geben an, ob Neptune sie unterstützt oder nicht. ### Neptune-Unterstützung für `graph`-Features Die Neptune-Diagramm-Features (wenn vorhanden) sind mit den Features identisch, die vom Befehl `graph.features()` zurückgegeben würden. | | | Diagramm-Feature | Aktiviert? | | --- |--- | | Transactions | true | | ThreadedTransactions | false | | Computer | false | | Persistence | true | | ConcurrentAccess | true | ### Neptune-Unterstützung für Variablen-Features | | | Variablen-Feature | Aktiviert? | | --- |--- | | Variables | false | | SerializableValues | false | | UniformListValues | false | | BooleanArrayValues | false | | DoubleArrayValues | false | | IntegerArrayValues | false | | StringArrayValues | false | | BooleanValues | false | | ByteValues | false | | DoubleValues | false | | FloatValues | false | | IntegerValues | false | | LongValues | false | | MapValues | false | | MixedListValues | false | | StringValues | false | | ByteArrayValues | false | | FloatArrayValues | false | | LongArrayValues | false | ### Neptune-Unterstützung für Eckpunkt-Features | | | Eckpunkt-Feature | Aktiviert? | | --- |--- | | MetaProperties | false | | DuplicateMultiProperties | false | | AddVertices | true | | RemoveVertices | true | | MultiProperties | true | | UserSuppliedIds | true | | AddProperty | true | | RemoveProperty | true | | NumericIds | false | | StringIds | true | | UuidIds | false | | CustomIds | false | | AnyIds | false | ### Neptune-Unterstützung für Eckpunkt-Eigenschafts-Features | | | Eckpunkt-Eigenschafts-Feature | Aktiviert? | | --- |--- | | UserSuppliedIds | false | | AddProperty | true | | RemoveProperty | true | | NumericIds | true | | StringIds | true | | UuidIds | false | | CustomIds | false | | AnyIds | false | | Properties | true | | SerializableValues | false | | UniformListValues | false | | BooleanArrayValues | false | | DoubleArrayValues | false | | IntegerArrayValues | false | | StringArrayValues | false | | BooleanValues | true | | ByteValues | true | | DoubleValues | true | | FloatValues | true | | IntegerValues | true | | LongValues | true | | MapValues | false | | MixedListValues | false | | StringValues | true | | ByteArrayValues | false | | FloatArrayValues | false | | LongArrayValues | false | ### Neptune-Unterstützung für Kanten-Features | | | Kanten-Feature | Aktiviert? | | --- |--- | | AddEdges | true | | RemoveEdges | true | | UserSuppliedIds | true | | AddProperty | true | | RemoveProperty | true | | NumericIds | false | | StringIds | true | | UuidIds | false | | CustomIds | false | | AnyIds | false | ### Neptune-Unterstützung für Kanten-Eigenschafts-Features | | | Kanten-Eigenschafts-Feature | Aktiviert? | | --- |--- | | Properties | true | | SerializableValues | false | | UniformListValues | false | | BooleanArrayValues | false | | DoubleArrayValues | false | | IntegerArrayValues | false | | StringArrayValues | false | | BooleanValues | true | | ByteValues | true | | DoubleValues | true | | FloatValues | true | | IntegerValues | true | | LongValues | true | | MapValues | false | | MixedListValues | false | | StringValues | true | | ByteArrayValues | false | | FloatArrayValues | false | | LongArrayValues | false | # Einhaltung von SPARQL-Standards in Amazon Neptune Nach der Auflistung der geltenden SPARQL-Standards enthalten die folgenden Abschnitte spezifische Informationen dazu, wie die SPARQL-Implementierung von Neptune diese Standards erweitert oder von ihnen abweicht. **Topics** + [Geltende Standards für SPARQL](#feature-sparql-applicable-standards) + [Standardpräfixe für Namespaces in Neptune SPARQL](#sparql-default-prefixes) + [SPARQL-Standard-Graph und benannte Graphen](#sparql-default-graph) + [Von Neptune unterstützte XPath SPARQL-Konstruktorfunktionen](#access-graph-sparql-xpath-constructors) + [Standard-Basis-IRI für Abfragen und Updates](#opencypher-compliance-default-iri) + [xsd:dateTime Werte in Neptune](#access-graph-sparql-xsd-date-time) + [Behandlung spezieller Gleitkommawerte in Neptune](#feature-overview-special-values-comparisons) + [Begrenzung von Werten beliebiger Länge in Neptune](#feature-overview-arbitrary-length-values) + [Neptune erweitert den Equals-Vergleich in SPARQL](#feature-overview-sparql-not-equal) + [Umgang mit Out-of-Range Literalen in Neptune SPARQL](#feature-overview-sparql-out-of-range) Amazon Neptune erfüllt bei der Implementierung der SPARQL-Diagrammabfragensprache die folgenden Standards. ## Geltende Standards für SPARQL + SPARQL wird vom W3C in der Empfehlung [SPARQL 1.1 Query Language](https://www.w3.org/TR/sparql11-query/) vom 21. März 2013 definiert. + Das SPARQL-Update-Protokoll und die Abfragesprache werden durch die W3C [SPARQL 1.1-Update](https://www.w3.org/TR/sparql11-update/)-Spezifikation definiert. + Für numerische Formate folgt SPARQL den in [W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes](https://www.w3.org/TR/xmlschema11-2/) beschriebenen Spezifikationen, die mit der IEEE 754-Spezifikation ([IEEE 754-2019 – IEEE Standard for Floating-Point Arithmetic](https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html) konsistent sind. (Weitere Informationen finden Sie auch auf der [Wikipedia-Seite zu IEEE 754](https://en.wikipedia.org/wiki/IEEE_754)). Funktionen, die nach Version `IEEE 754-1985` eingeführt wurden, sind in der Spezifikation jedoch nicht enthalten. ## Standardpräfixe für Namespaces in Neptune SPARQL Neptune definiert standardmäßig die folgenden Präfixe für die Verwendung in SPARQL-Abfragen. Weitere Informationen finden Sie unter [Präfixnamen](https://www.w3.org/TR/sparql11-query/#prefNames) in der SPARQL-Spezifikation. + `rdf`  – `http://www.w3.org/1999/02/22-rdf-syntax-ns#` + `rdfs` – `http://www.w3.org/2000/01/rdf-schema#` + `owl`  – `http://www.w3.org/2002/07/owl#` + `xsd`  – `http://www.w3.org/2001/XMLSchema#` ## SPARQL-Standard-Graph und benannte Graphen Amazon Neptune ordnet jedem Triple einen benannten Graphen zu. Der Standard-Graph ist als die Vereinigung aller benannten Graphen definiert. **Standard-Graph für Abfragen** Wenn Sie eine SPARQL-Anfrage absenden, ohne ausdrücklich einen Graphen über das `GRAPH`-Schlüsselwort oder Konstrukte wie `FROM NAMED` anzugeben, berücksichtigt Neptune stets alle Triples in Ihrer DB-Instance. Die folgende Abfrage gibt beispielsweise alle Triples von einem Neptune-SPARQL-Endpunkt zurück: `SELECT * WHERE { ?s ?p ?o }` Triples, die in mehr als einem Graphen vorhanden sind, werden nur einmal zurückgegeben. Weitere Informationen über die Standard-Graph-Spezifikation finden Sie im [RDF-Dataset](https://www.w3.org/TR/sparql11-query/#rdfDataset)-Abschnitt der Query Language SPARQL 1.1-Spezifikation. **Angeben des benannten Graphen für Ladevorgänge, Einfügungen oder Updates** Wenn Sie beim Laden, Einfügen oder Aktualisieren von Triples keinen benannten Graphen angeben, verwendet Neptune den benannten Fallback-Graphen, der durch die URI `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph` definiert ist. Wenn Sie eine Neptune-`Load`-Anforderung in einem Triple-basierten Format ausgeben, können Sie mit dem Parameter `parserConfiguration: namedGraphUri` angeben, dass der genannte Graph für alle Triples verwendet werden soll. Weitere Informationen zur `Load`-Befehlssyntax finden Sie unter [Neptune-Loader-Befehl](load-api-reference-load.md). **Wichtig** Wenn Sie diesen Parameter nicht benutzen und keinen benannten Graphen angeben, wird die Fallback-URI verwendet: `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`. Dieser benannte Fallback-Graph wird auch verwendet, wenn Sie Triples über `SPARQL UPDATE` laden, ohne ausdrücklich einen benannten Ziel-Graphen anzugeben. Sie können das Quads-basierte Format N-Quads verwenden, um einen benannten Graphen für jedes Triple in der Datenbank anzugeben. **Anmerkung** N-Quads erlaubt es, das Feld für den benannten Graphen leer zu lassen. In diesem Fall wird `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph` verwendet. Sie können den standardmäßigen benannten Graphen für N-Quads überschreiben, indem Sie die Parser-Konfigurationsoption `namedGraphUri` verwenden. ## Von Neptune unterstützte XPath SPARQL-Konstruktorfunktionen Der SPARQL-Standard ermöglicht SPARQL-Engines die Unterstützung eines erweiterbaren Satzes von Konstruktorfunktionen. XPath Neptune unterstützt zurzeit die folgenden Konstruktorfunktionen, wobei das `xsd`-Präfix als `http://www.w3.org/2001/XMLSchema#` definiert ist: + `xsd:boolean` + `xsd:integer` + `xsd:double` + `xsd:float` + `xsd:decimal` + `xsd:long` + `xsd:unsignedLong` ## Standard-Basis-IRI für Abfragen und Updates Da ein Neptune-Cluster über mehrere verschiedene Endpunkte verfügt, kann die Verwendung der Anforderungs-URL einer Abfrage oder eines Updates als Basis-IRI zu unerwarteten Ergebnissen bei der Auflösung relativer Daten führen. IRIs Ab [Engine-Version 1.2.1.0](engine-releases-1.2.1.0.md) verwendet Neptune `http://aws.amazon.com/neptune/default/` als Basis-IRI, wenn kein expliziter Basis-IRI Teil der Anforderung ist. In der folgenden Anforderung ist der Basis-IRI Teil der Anforderung: ``` BASE INSERT DATA { "n1" } BASE SELECT * { ?p ?o } ``` Das Ergebnis wäre: ``` ?p ?o http://example.org/default/id n1 ``` In dieser Anforderung ist jedoch kein Basis-IRI enthalten: ``` INSERT DATA { "n1" } SELECT * { ?p ?o } ``` In diesem Fall wäre das Ergebnis: ``` ?p ?o http://aws.amazon.com/neptune/default/id n1 ``` ## xsd:dateTime Werte in Neptune Aus Leistungsgründen speichert Neptune date/time Werte immer als koordinierte Weltzeit (UTC). Dies macht direkte Vergleiche sehr effizient. Es bedeutet auch, dass Neptune den Wert in UTC übersetzt und die Zeitzoneninformationen verwirft, wenn Sie einen `dateTime`-Wert eingeben, der eine bestimmte Zeitzone angibt. Wenn Sie den `dateTime`-Wert später abrufen, wird er in UTC ausgedrückt, nicht in der Zeit der ursprünglichen Zeitzone, und Sie können nicht mehr erkennen, was die ursprüngliche Zeitzone war. ## Behandlung spezieller Gleitkommawerte in Neptune Neptune behandelt spezielle Gleitkommawerte in SPARQL wie folgt. ### SPARQL-NaN-Behandlung in Neptune SPARQL kann in Neptune einen Wert von `NaN` in einer Abfrage akzeptieren. Es gibt keine Unterscheidung zwischen signalisierenden und stillen `NaN`-Werten. Neptune behandelt alle `NaN`-Werte als stille Werte. Semantisch ist kein Vergleich mit einem `NaN`-Wert möglich, da nichts größer als, kleiner als oder gleich einem `NaN`-Wert ist. Das bedeutet, dass ein Wert von `NaN` auf der einen Seite eines Vergleichs theoretisch mit *nichts* auf der anderen Seite übereinstimmen kann. Die [XSD-Spezifikation](https://www.w3.org/TR/xmlschema-2/#double) behandelt jedoch zwei `xsd:double`- oder `xsd:float`-`NaN`Werte als gleich. Neptune folgt dem für den Filter `IN`, für den Gleichheiteroperator in Filterausdrücken und für die exakte Übereinstimmungssemantik (mit einem `NaN`-Wert in der Objektposition eines Triple-Musters). ### Behandlung unendlicher SPARQL-Werte in Neptune SPARQL kann in Neptune einen Wert von `-INF` oder `INF` in einer Abfrage akzeptieren. `INF` ist in Vergleichen größer als jeder andere numerische Wert; `-INF` ist in Vergleichen kleiner als jeder andere numerische Wert. Zwei INF-Werte mit übereinstimmenden Vorzeichen werden unabhängig vom Typ als gleich behandelt (z. B. gilt ein Float-`-INF` als gleich einem Double-`-INF`). Selbstverständlich ist mit `NaN` kein Vergleich möglich, denn nichts ist größer, kleiner oder gleich `NaN`. ### Behandlung einer negativen SPARQL-Null in Neptune Neptune normalisiert einen negativen Nullwert zu einer Null ohne Vorzeichen. Sie können negative Nullwerte in einer Abfrage verwenden. Sie werden jedoch nicht als solche in der Datenbank aufgezeichnet und bei Vergleichen entsprechen sie Nullen ohne Vorzeichen. ## Begrenzung von Werten beliebiger Länge in Neptune Neptune begrenzt die Speichergröße von XSD-Ganzzahl-, Gleitkomma- und Dezimalwerten in SPARQL auf 64 Bit. Die Verwendung von größeren Werten führt zum Fehler `InvalidNumericDataException`. ## Neptune erweitert den Equals-Vergleich in SPARQL Der SPARQL-Standard definiert eine ternäre Logik für Wertausdrücke, wobei ein Wertausdruck als `true`, `false` oder `error` bewertet werden kann. Die Standardsemantik für Begriffsgleichheit (wie in der [SPARQL 1.1-Spezifikation](https://www.w3.org/TR/sparql11-query/#func-RDFterm-equal) definiert), die für die Vergleiche `=` und `!=` in `FILTER`-Bedingungen gilt, erzeugt einen `error` beim Vergleich von Datentypen, die in der [Operatoren-Tabelle](https://www.w3.org/TR/sparql11-query/#OperatorMapping) nicht explizit vergleichbar sind. Dieses Verhalten kann zu Ergebnissen, wie im folgenden Beispiel, führen, die nicht intuitiv sind. Daten: ``` "127.0.0.1"^^ ``` Abfrage 1: ``` SELECT * WHERE { ?o . FILTER(?o = "127.0.0.2"^^) } ``` Abfrage 2: ``` SELECT * WHERE { ?o . FILTER(?o != "127.0.0.2"^^) } ``` Mit der SPARQL-Standardsemantik, die Neptune vor Version 1.0.2.1 verwendet hat, würden beide Abfragen ein leeres Ergebnis zurückgeben. Der Grund hierfür ist, dass `?o = "127.0.0.2"^^` bei der Auswertung für `?o := "127.0.0.1"^^` einen `error` statt `false` erzeugt, weil keine expliziten Vergleichsregeln für den benutzerdefinierten Datentyp `` angegeben sind. Infolgedessen erzeugt die negierte Version in der zweiten Abfrage auch einen `error`. In beiden Abfragen bewirkt der `error`, dass die Kandidatenlösung herausgefiltert wird. Ab Version 1.0.2.1 erweitert Neptune den SPARQL-Ungleichheitsoperator entsprechend der Spezifikation. Weitere Informationen finden Sie im [Abschnitt von SPARQL 1.1 zur Operator-Erweiterbarkeit](https://www.w3.org/TR/sparql11-query/#operatorExtensibility), in dem Engines zusätzliche Regeln für den Vergleich zwischen benutzerdefinierten und nicht vergleichbaren integrierten Datentypen definieren können. Bei Verwendung dieser Option bewertet Neptune jetzt den Vergleich zwischen zwei in der Operator-Zuweisungstabelle nicht explizit definierten Datentypen als `true`, wenn die Literalwerte und Datentypen syntaktisch gleich sind. Andernfalls wird der Vergleich als „false“ bewertet. Ein `error` wird in keinem Fall erstellt. Mit dieser neuen Semantik würde die zweite Abfrage `"127.0.0.1"^^` anstelle eines leeren Ergebnisses zurückgeben. ## Umgang mit Out-of-Range Literalen in Neptune SPARQL Mit der XSD-Semantik wird jeder numerische Typ mit seinem Wertebereich definiert, abgesehen von `integer` und `decimal`. Diese Definitionen beschränken jeden Typ auf einen Wertebereich. Beispielsweise liegt der Umfang eines `xsd:byte`-Bereichs zwischen -128 und \$1127. Jeder Wert außerhalb dieses Bereichs gilt als ungültig. Wenn Sie versuchen, einen Literalwert außerhalb des Werteraums eines Typs zuzuweisen (wenn Sie beispielsweise versuchen, an auf einen Literalwert von 999 `xsd:byte` zu setzen), akzeptiert Neptune den out-of-range Wert unverändert, ohne ihn zu runden oder zu kürzen. Allerdings bleibt der Wert nicht als numerischer Wert erhalten, da der angegebene Typ ihn nicht darstellen kann. Das heißt, Neptune akzeptiert `"999"^^xsd:byte`, obwohl es sich um einen Wert außerhalb des definierten `xsd:byte`-Wertebereichs handelt. Nachdem der Wert jedoch in der Datenbank beibehalten wurde, kann er in der exakten Übereinstimmungssemantik nur in einer Objektposition eines dreifachen Musters verwendet werden. Darauf kann kein Bereichsfilter ausgeführt werden, da out-of-range Literale nicht als numerische Werte behandelt werden. Die SPARQL 1.1-Spezifikation definiert [Bereichsoperatoren](https://www.w3.org/TR/sparql11-query/#OperatorMapping) im Format `numeric`*-Operator-*`numeric`, `string`*-Operator-*`string`, `literal`*-Operator-*`literal` usw. Neptune kann keine Bereichsvergleichsoperatoren wie `invalid-literal`*-operator-*`numeric-value` ausführen. # Einhaltung der OpenCypher-Spezifikationen in Amazon Neptune Die Amazon Neptune-Version von openCypher unterstützt im Allgemeinen die Klauseln, Operatoren, Ausdrücke, Funktionen und Syntax, die in [Cypher Query Language Reference Version 9](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf) definiert sind, der aktuellen openCypher-Spezifikation. Im Folgenden werden die Einschränkungen und Unterschiede bei der Neptune-Unterstützung für openCypher beschrieben. Amazon Neptune unterstützt auch mehrere Funktionen, die über den Rahmen der OpenCypher-Spezifikation hinausgehen. Weitere Einzelheiten finden Sie unter [OpenCypher-Erweiterungen in Amazon Neptune](access-graph-opencypher-extensions.md). **Anmerkung** Die aktuelle Neo4j-Implementierung von Cypher enthält Funktionen, die nicht in der oben genannten openCypher-Spezifikation enthalten sind. Wenn Sie aktuellen Cypher-Code zu Neptune migrieren, finden Sie unter [Neptune-Kompatibilität mit Neo4j](migration-compatibility.md) und [Umschreiben von Cypher-Abfragen zur Ausführung in openCypher auf Neptune](migration-opencypher-rewrites.md) weitere Informationen. ## Unterstützung für openCypher-Klauseln in Neptune Neptune unterstützt die folgenden Klauseln, wenn nicht anders angegeben: + `MATCH`   –   Unterstützt, jedoch werden *`shortestPath()`* und *`allShortestPaths()`* zurzeit nicht unterstützt. + `OPTIONAL MATCH` + *`MANDATORY MATCH`*   –   Zurzeit **nicht** in Neptune unterstützt. Neptune unterstützt jedoch [benutzerdefinierte ID-Werte`MATCH` in ](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids)-Abfragen. + `RETURN`   –   Unterstützt, jedoch nicht in Verbindung mit nichtstatischen Werten für `SKIP` oder `LIMIT`. Beispielsweise funktioniert Folgendes zurzeit nicht: ``` MATCH (n) RETURN n LIMIT toInteger(rand()) // Does NOT work! ``` + `WITH`   –   Unterstützt, jedoch nicht in Verbindung mit nichtstatischen Werten für `SKIP` oder `LIMIT`. Beispielsweise funktioniert Folgendes zurzeit nicht: ``` MATCH (n) WITH n SKIP toInteger(rand()) WITH count() AS count RETURN count > 0 AS nonEmpty // Does NOT work! ``` + `UNWIND` + `WHERE` + `ORDER BY` + `SKIP` + `LIMIT` + `CREATE`   –   Sie können mit Neptune [benutzerdefinierte ID-Werte](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids) in `CREATE`-Abfragen erstellen. + `DELETE` + `SET` + `REMOVE` + `MERGE`   –   Neptune unterstützt [benutzerdefinierte ID-Werte](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids) in `MERGE`-Abfragen. + *`CALL[YIELD...]`*   –   Zurzeit **nicht** in Neptune unterstützt. + `UNION, UNION ALL`   –   Schreibgeschützte Abfragen werden unterstützt, Mutationsabfragen werden zurzeit jedoch **nicht** unterstützt. + `USING`[— `USING` wird ab Engine-Version 1.3.2.0 unterstützt.](https://docs.aws.amazon.com//neptune/latest/userguide/engine-releases-1.3.2.0.html) Weitere Informationen finden Sie unter [Abfragehinweise](https://docs.aws.amazon.com//neptune/latest/userguide/opencypher-query-hints.html). ## Unterstützung für openCypher-Operatoren in Neptune Neptune unterstützt die folgenden Operatoren, wenn nicht anders angegeben: **Allgemeine Operatoren** + `DISTINCT` + `.` Operator für den Zugriff auf Eigenschaften einer verschachtelten Literalmap. **Mathematische Operatoren** + `+` Additionsoperator. + `-` Subtraktionsoperator. + `*` Multiplikationsoperator. + `/` Teilungsoperator. + `%` Modulo-Teilungsoperator. + Der `^` Potenzierungsoperator. *is NOT supported* **Vergleichsoperatoren** + `=` Additionsoperator. + `<>` Ungleichheitsoperator. + Der `<` Kleiner-Als-Operator wird unterstützt, es sei denn, eines der Argumente ist Path, List oder Map. + Der `>` Größer-Als-Operator wird unterstützt, es sei denn, eines der Argumente ist Path, List oder Map. + Der Operator `<=` less-than-or-equal -to wird unterstützt, außer wenn eines der Argumente ein Path, List oder Map ist. + Der Operator `>=` greater-than-or-equal -to wird unterstützt, außer wenn eines der Argumente ein Path, List oder Map ist. + `IS NULL` + `IS NOT NULL` + `STARTS WITH` wird unterstützt, wenn es sich bei den gesuchten Daten um eine Zeichenfolge handelt. + `ENDS WITH` wird unterstützt, wenn es sich bei den gesuchten Daten um eine Zeichenfolge handelt. + `CONTAINS` wird unterstützt, wenn es sich bei den gesuchten Daten um eine Zeichenfolge handelt. **Boolesche Operatoren** + `AND` + `OR` + `XOR` + `NOT` **Zeichenfolgenoperatoren** + `+` Verkettungsoperator. **Listenoperatoren.** + `+` Verkettungsoperator. + `IN` (überprüft auf Vorhandensein eines Elements in der Liste) ## Unterstützung für openCypher-Ausdrücke in Neptune Neptune unterstützt die folgenden Ausdrücke, wenn nicht anders angegeben: + `CASE` + Der `[]`-Ausdruck wird zurzeit in Neptune **nicht** für den Zugriff auf dynamisch berechnete Eigenschaftsschlüssel innerhalb eines Knotens, einer Beziehung oder einer Map unterstützt. Beispielsweise funktioniert Folgendes nicht: ``` MATCH (n) WITH [5, n, {key: 'value'}] AS list RETURN list[1].name ``` ## Unterstützung für openCypher-Funktionen in Neptune Neptune unterstützt die folgenden Funktionen, wenn nicht anders angegeben: **Prädikatsfunktionen** + `exists()` **Skalarfunktionen** + `coalesce()` + `endNode()` + `epochmillis()` + `head()` + `id()` + `last()` + `length()` + `randomUUID()` + `properties()` + `removeKeyFromMap` + `size()`   –   Diese Methodenüberladung funktioniert zurzeit nur für Musterausdrücke, Listen und Zeichenfolgen. + `startNode()` + `timestamp()` + `toBoolean()` + `toFloat()` + `toInteger()` + `type()` **Aggregationsfunktionen** + `avg()` + `collect()` + `count()` + `max()` + `min()` + `percentileDisc()` + `stDev()` + `percentileCont()` + `stDevP()` + `sum()` **Listenfunktionen** + [`join()`](access-graph-opencypher-extensions.md#opencypher-compliance-join-function) (verkettet Zeichenfolgen in einer Liste zu einer einzigen Zeichenfolge) + `keys()` + `labels()` + `nodes()` + `range()` + `relationships()` + `reverse()` + `tail()` **Mathematische Funktionen – numerisch** + `abs()` + `ceil()` + `floor()` + `rand()` + `round()` + `sign()` **Mathematische Funktionen – logarithmisch** + `e()` + `exp()` + `log()` + `log10()` + `sqrt()` **Mathematische Funktionen – trigonometrisch** + `acos()` + `asin()` + `atan()` + `atan2()` + `cos()` + `cot()` + `degrees()` + `pi()` + `radians()` + `sin()` + `tan()` **Zeichenfolgenfunktionen** + [`join()`](access-graph-opencypher-extensions.md#opencypher-compliance-join-function) (verkettet Zeichenfolgen in einer Liste zu einer einzigen Zeichenfolge) + `left()` + `lTrim()` + `replace()` + `reverse()` + `right()` + `rTrim()` + `split()` + `substring()` + `toLower()` + `toString()` + `toUpper()` + `trim()` **Benutzerdefinierte Funktionen** *User-defined functions*werden derzeit in Neptune **nicht** unterstützt. ## Neptune-spezifische openCypher-Implementierungsdetails Die folgenden Abschnitte beschreiben, wie sich die Neptune-Implementierung von openCypher von der [openCypher-Spezifikation](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf) unterscheidet oder über diese hinausgeht. ### Evaluierungen von Pfaden variabler Länge (VLP) in Neptune Evaluierungen von Pfaden (`VLP`) variabler Länge entdecken Pfade zwischen Knoten im Diagramm. Die Pfadlänge in einer Abfrage kann uneingeschränkt sein. Um Zyklen zu verhindern, legt die [openCypher-Spezifikation](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf) fest, dass jede Kante höchstens einmal pro Lösung traversiert werden darf. Denn VLPs die Neptune-Implementierung weicht von der OpenCypher-Spezifikation insofern ab, als sie nur konstante Werte für Eigenschaftsgleichheitsfilter unterstützt. Führen Sie die folgende Abfrage aus: ``` MATCH (x)-[:route*1..2 {dist:33, code:x.name}]->(y) return x,y ``` Da der Wert des `x.name`-Eigenschaftsgleichheitsfilters keine Konstante ist, führt diese Abfrage zu einer `UnsupportedOperationException` mit der folgenden Meldung: `Property predicate over variable-length relationships with non-constant expression is not supported in this release.` ### Temporale Unterstützung in der Neptune OpenCypher-Implementierung (Neptune-Datenbank 1.3.1.0 und niedriger) Neptune stellt zurzeit eine eingeschränkte Unterstützung für temporale Funktionen in openCypher bereit. Die Lösung unterstützt den Datentyp `DateTime` für temporale Typen. Die Funktion `datetime()` kann verwendet werden, um die aktuellen Werte für UTC-Datum und -Uhrzeit wie folgt abzurufen: ``` RETURN datetime() as res ``` Datums- und Uhrzeitwerte können aus Zeichenfolgen im Format `"`*date*`T`*time*`"` analysiert werden, wobei *date* und *time* in einem der folgenden unterstützten Formate ausgedrückt werden: **Unterstützte Datumsformate** + `yyyy-MM-dd` + `yyyyMMdd` + `yyyy-MM` + `yyyy-DDD` + `yyyyDDD` + `yyyy` **Unterstützte Uhrzeitformate** + `HH:mm:ssZ` + `HHmmssZ` + `HH:mm:ssZ` + `HH:mmZ` + `HHmmZ` + `HHZ` + `HHmmss` + `HH:mm:ss` + `HH:mm` + `HHmm` + `HH` Beispiel: ``` RETURN datetime('2022-01-01T00:01') // or another example: RETURN datetime('2022T0001') ``` Beachten Sie, dass alle date/time Werte in Neptune OpenCypher als UTC-Werte gespeichert und abgerufen werden. Neptune openCypher verwendet eine `statement`-Uhr. Das bedeutet, dass über die Dauer einer Abfrage derselbe Zeitpunkt verwendet wird. Eine andere Abfrage innerhalb derselben Transaktion verwendet möglicherweise einen anderen Zeitpunkt. Neptune unterstützt keine Verwendung von Funktionen innerhalb von Aufrufen von `datetime()`. Beispielsweise funktioniert Folgendes nicht: ``` CREATE (:n {date:datetime(tostring(2021))}) // ---> NOT ALLOWED! ``` Neptune unterstützt die Funktion `epochmillis()`, die einen `datetime`-Wert in `epochmillis` konvertiert. Beispiel: ``` MATCH (n) RETURN epochMillis(n.someDateTime) 1698972364782 ``` Neptune unterstützt zurzeit keine anderen Funktionen und Operationen für `DateTime`-Objekte, z. B. Addition und Subtraktion. ### Temporale Unterstützung in der Neptune OpenCypher-Implementierung (Neptune Analytics und Neptune Database 1.3.2.0 und höher) Die folgende Datetime-Funktionalität für OpenCypher gilt für Neptune Analytics. Alternativ können Sie den Labmode-Parameter `DatetimeMillisecond=enabled` verwenden, um die folgenden Datetime-Funktionen auf Neptune Engine-Release-Version 1.3.2.0 und höher zu aktivieren. Weitere Informationen zur Verwendung dieser Funktionalität im Labmode finden Sie unter. [Erweiterte Datetime-Unterstützung](features-lab-mode.md#labmode-extended-datetime-support) + Support für Millisekunden. Das Datetime-Literal wird immer mit Millisekunden zurückgegeben, auch wenn Millisekunden 0 ist. (Bisheriges Verhalten bestand darin, Millisekunden zu kürzen.) ``` CREATE (:event {time: datetime('2024-04-01T23:59:59Z')}) # Returning the date returns with 000 suffixed representing milliseconds MATCH(n:event) RETURN n.time as datetime { "results" : [ { "n" : { "~id" : "0fe88f7f-a9d9-470a-bbf2-fd6dd5bf1a7d", "~entityType" : "node", "~labels" : [ "event" ], "~properties" : { "time" : "2024-04-01T23:59:59.000Z" } } } ] } ``` + Support für den Aufruf der Funktion datetime () über gespeicherte Eigenschaften oder Zwischenergebnisse. Beispielsweise waren die folgenden Abfragen vor dieser Funktion nicht möglich. Datetime () über Eigenschaften: ``` // Create node with property 'time' stored as string CREATE (:event {time: '2024-04-01T23:59:59Z'}) // Match and return this property as datetime MATCH(n:event) RETURN datetime(n.time) as datetime ``` Datetime () im Vergleich zu Zwischenergebnissen: ``` // Parse datetime from parameter UNWIND $list as myDate RETURN datetime(myDate) as d ``` + Es ist jetzt auch möglich, Datetime-Eigenschaften zu speichern, die in den oben genannten Fällen erstellt wurden. Speichern von Datetime aus der String-Eigenschaft einer Eigenschaft in eine andere: ``` // Create node with property 'time' stored as string CREATE (:event {time: '2024-04-01T23:59:59Z', name: 'crash'}) // Match and update the same property to datetime type MATCH(n:event {name: 'crash'}) SET n.time = datetime(n.time) // Match and update another node's property MATCH(e:event {name: 'crash'}) MATCH(n:server {name: e.servername}) SET n.time = datetime(e.time) ``` Erstellen Sie im Batch-Modus Knoten aus einem Parameter mit einer Datetime-Eigenschaft: ``` // Batch create from parameter UNWIND $list as events CREATE (n:crash) {time: datetime(events.time)} // Parameter value { "x":[ {"time":"2024-01-01T23:59:29", "name":"crash1"}, {"time":"2023-01-01T00:00:00Z", "name":"crash2"} ] } ``` + Support für eine größere Teilmenge von ISO8601 Datetime-Formaten. Weitere Informationen finden Sie unter weiter unten in diesem Dokument. Unterstützte Formate Das Format eines Datetime-Werts ist [Date] T [Time] [Timezone], wobei T das Trennzeichen ist. Wenn keine explizite Zeitzone angegeben wird, wird UTC (Z) als Standard angenommen. Zeitzone Folgende Zeitzonenformate werden unterstützt: + \$1/-hh:mm + \$1/-HHmm + \$1/-HH Das Vorhandensein einer Zeitzone in einer Datetime-Zeichenfolge ist optional. Falls der Zeitzonen-Offset 0 ist, kann Z anstelle des obigen Zeitzonen-Postfixes verwendet werden, um die UTC-Zeit anzugeben. Der unterstützte Bereich einer Zeitzone liegt zwischen -14:00 und \$1 14:00 Uhr. Date Wenn keine Zeitzone vorhanden ist oder die Zeitzone UTC (Z) ist, lauten die unterstützten Datumsformate wie folgt: **Anmerkung** DDD bezieht sich auf ein Ordinaldatum, das für einen Tag des Jahres von 001 bis 365 steht (366 in Schaltjahren). 2024-002 steht beispielsweise für den 2. Januar 2024. + `yyyy-MM-dd` + `yyyyMMdd` + `yyyy-MM` + `yyyyMM` + `yyyy-DDD` + `yyyyDDD` + `yyyy` Wenn eine andere Zeitzone als Z ausgewählt wird, sind die unterstützten Datumsformate auf die folgenden beschränkt: + `yyyy-MM-dd` + `yyyy-DDD` + `yyyyDDD` Der unterstützte Datumsbereich reicht von 1400-01-01 bis 9999-12-31. Zeit Wenn keine Zeitzone vorhanden ist oder die Zeitzone UTC (Z) ist, werden folgende Zeitformate unterstützt: + `HH:mm:ss.SSS` + `HH:mm:ss` + `HHmmss.SSS` + `HHmmss` + `HH:mm` + `HHmm` + `HH` Wenn eine andere Zeitzone als Z ausgewählt wird, sind die unterstützten Zeitformate auf die folgenden beschränkt: + `HH:mm:ss` + `HH:mm:ss.SSS` ### Unterschiede bei der Semantik der Neptune-openCypher-Sprache Neptune repräsentiert Knoten und Beziehung IDs als Zeichenketten und nicht als Ganzzahlen. Die ID entspricht der ID, die über den Datenloader bereitgestellt wird. Wenn es einen Namespace für die Spalte gibt, entspricht sie dem Namespace und der ID. Daher gibt die Funktion `id` eine Zeichenfolge statt einer Ganzzahl zurück. Der Datentyp `INTEGER` ist auf 64 Bit begrenzt. Wenn Sie mittels der Funktion `TOINTEGER` größere Fließkomma- oder Zeichenfolgenwerte in eine Ganzzahl konvertieren, werden negative Werte zu `LLONG_MIN` und positive Werte zu `LLONG_MAX` verkürzt. Beispiel: ``` RETURN TOINTEGER(2^100) > 9223372036854775807 RETURN TOINTEGER(-1 * 2^100) > -9223372036854775808 ``` ### Mehrwertige Eigenschaften Obwohl OpenCypher CREATE keine mehrwertigen Eigenschaften erstellt, können sie in Daten vorkommen, die mit Gremlin (Neptune Database) erstellt wurden, oder beim Laden von Daten (Neptune Database und Neptune Analytics). Wenn Neptune openCypher eine Eigenschaft mit mehreren Werten findet, wird ein Wert zufällig ausgewählt, was zu einem nicht deterministischen Ergebnis führt. ### Umgang mit NaN-Werten Neptuns Umgang mit dem Vergleich von `NaN` Eigenschaftswerten ist nicht definiert. Sich auf solche Vergleiche zu verlassen, kann zu unerwarteten oder nicht deterministischen Ergebnissen führen.