Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Note sulla conformità agli standard di Amazon Neptune Amazon Neptune è conforme agli standard applicabili nell'implementazione dei linguaggi di query a grafo Gremlin e SPARQL nella maggior parte dei casi. Queste sezioni descrivono gli standard e le aree in cui Neptune si estende o si discosta da essi. **Topics** + [Conformità agli standard Gremlin in Amazon Neptune](access-graph-gremlin-differences.md) + [Conformità agli standard SPARQL in Amazon Neptune](feature-sparql-compliance.md) + [Conformità alle specifiche OpenCypher in Amazon Neptune](feature-opencypher-compliance.md) # Conformità agli standard Gremlin in Amazon Neptune Le seguenti sezioni forniscono una panoramica dell'implementazione di Neptune di Gremlin e di come si differenzia dall'implementazione di Apache. TinkerPop Neptune implementa alcuni passaggi di Gremlin in modo nativo nel suo motore e utilizza l'implementazione di TinkerPop Apache Gremlin per elaborarne altri (vedi). [Supporto nativo dei passaggi Gremlin in Amazon Neptune](gremlin-step-support.md) **Nota** Per alcuni esempi concreti di queste differenze di implementazione mostrate nella console Gremlin e in Amazon Neptune, consulta la sezione [Utilizzo di Gremlin per accedere ai dati dei grafici in Amazon Neptune](get-started-graph-gremlin.md) del Quick Start. **Topics** + [Standard applicabili per Gremlin](#feature-gremlin-applicable-standards) + [Variabili e parametri negli script](#feature-gremlin-differences-variables) + [TinkerPop enumerazioni](#feature-gremlin-differences-tinkerpop) + [Codice Java](#feature-gremlin-differences-java) + [Proprietà degli elementi](#feature-gremlin-differences-properties-on-elements) + [Esecuzione di uno script](#feature-gremlin-differences-script) + [Sessioni](#feature-gremlin-differences-sessions) + [Transazioni](#feature-gremlin-differences-transactions) + [Vertice e spigolo IDs](#feature-gremlin-differences-vertex-edge-ids) + [Fornito dall'utente IDs](#feature-gremlin-differences-user-supplied-ids) + [Proprietà Vertex IDs](#feature-gremlin-differences-vertex-property-ids) + [Cardinalità delle proprietà dei vertici](#feature-gremlin-differences-vertex-property-cardinality) + [Aggiornamento della proprietà di un vertice](#feature-gremlin-differences-vertex-property-update) + [Etichette](#feature-gremlin-differences-labels) + [Caratteri escape](#feature-gremlin-differences-escapes) + [Limitazioni Groovy](#feature-gremlin-differences-groovy) + [Serializzazione](#feature-gremlin-differences-serialization) + [Passaggi Lambda](#feature-gremlin-differences-lambda) + [Metodi Gremlin non supportati](#feature-gremlin-differences-unsupported-methods) + [Passaggi Gremlin non supportati](#feature-gremlin-differences-unsupported-steps) + [Caratteristiche del grafo Gremlin in Neptune](#gremlin-api-reference-features) ## Standard applicabili per Gremlin + Il linguaggio Gremlin è definito da [Apache TinkerPop Documentation e dall'implementazione Apache](http://tinkerpop.apache.org/docs/current/reference/) di Gremlin piuttosto che da una specifica formale. TinkerPop + Per i formati numerici, Gremlin segue lo standard IEEE 754 ([IEEE 754-2019 - IEEE Standard for Floating-Point Arithmetic](https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html). Per ulteriori informazioni, consulta anche la [pagina IEEE 754 di Wikipedia](https://en.wikipedia.org/wiki/IEEE_754)). ## Variabili e parametri negli script Per quanto riguarda le variabili pre-bound, l'oggetto di attraversamento `g` è pre-bound in Neptune e l'oggetto `graph` non è supportato. Sebbene Neptune non supporti le variabili Gremlin o la parametrizzazione negli script, spesso si possono trovare in Internet script di esempio per Gremlin Server che contengono dichiarazioni di variabili, come ad esempio: ``` String query = "x = 1; g.V(x)"; List results = client.submit(query).all().get(); ``` Esistono anche molti esempi che utilizzano la [parametrizzazione](https://tinkerpop.apache.org/docs/current/reference/#parameterized-scripts) (o le associazioni) quando si inviano le query, come ad esempio: ``` Map params = new HashMap<>(); params.put("x",1); String query = "g.V(x)"; List results = client.submit(query).all().get(); ``` Gli esempi di parametri sono in genere associati ad avvisi relativi alle penalizzazioni in termini di prestazioni in caso di mancata parametrizzazione quando possibile. Di esempi simili ce ne sono moltissimi, e tutti sembrano abbastanza convincenti sulla necessità di parametrizzare. TinkerPop Tuttavia, sia la funzionalità di dichiarazione delle variabili che la funzionalità di parametrizzazione (insieme agli avvisi) si applicano al Gremlin Server solo quando TinkerPop utilizza il. `GremlinGroovyScriptEngine` Non si applicano quando Gremlin Server utilizza la grammatica ANTLR `gremlin-language` di Gremlin per analizzare le query. La grammatica ANTLR non supporta né le dichiarazioni di variabili né la parametrizzazione, quindi quando si utilizza ANTLR, non ci si deve preoccupare di non riuscire a parametrizzare. Poiché la grammatica ANTLR è un componente più recente di TinkerPop, i contenuti meno recenti che potresti incontrare su Internet generalmente non riflettono questa distinzione. Neptune utilizza la grammatica ANTLR nel motore di elaborazione delle query anziché `GremlinGroovyScriptEngine`, quindi non supporta le variabili, la parametrizzazione o la proprietà `bindings`. Di conseguenza, i problemi relativi alla mancata parametrizzazione non si applicano a Neptune. Utilizzando Neptune, è perfettamente sicuro inviare semplicemente la query così com'è, dove normalmente si parametrizza. Di conseguenza, l'esempio precedente può essere semplificato senza alcuna penalizzazione delle prestazioni come segue: ``` String query = "g.V(1)"; List results = client.submit(query).all().get(); ``` ## TinkerPop enumerazioni Neptune non supporta nomi di classe completi per i valori di enumerazione. Ad esempio, devi usare `single` e non `org.apache.tinkerpop.gremlin.structure.VertexProperty.Cardinality.single` nella richiesta Groovy. Il tipo di enumerazione è determinato dal tipo di parametro. La tabella seguente mostra i valori di enumerazione consentiti e il relativo nome completo. TinkerPop | Valori consentiti | Classe | | --- |--- | | 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.Cardinalità](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.Barriera](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.Scegli](https://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/process/traversal/Pick.html) | ## Codice Java Neptune non supporta chiamate a metodi definiti da chiamate arbitrarie a Java o a librerie Java diverse da quelle supportate da Gremlin. APIs Ad esempio, `java.lang.*`, `Date()`e `g.V().tryNext().orElseGet()` non sono consentite. ## Proprietà degli elementi Neptune non supporta `materializeProperties` il flag introdotto TinkerPop nella 3.7.0 per restituire proprietà sugli elementi. Di conseguenza, Neptune continuerà a restituire solo vertici o spigoli come riferimenti con la sola e. `id` `label` ## Esecuzione di uno script Tutte le query devono iniziare con `g`, l'oggetto di attraversamento. In Invii query stringa, possono essere emessi più attraversamenti separati da un punto e virgola (`;`) o un carattere nuova riga (`\n`). Per essere eseguita, ogni istruzione diversa dall'ultima deve terminare con una fase `.iterate()`. Vengono restituiti solo i dati di attraversamento finali. Nota che ciò non si applica agli invii di query ByteCode GLV. ## Sessioni Le sessioni in Neptune hanno una durata limitata di soli 10 minuti. Per ulteriori informazioni, consulta [Sessioni basate su script Gremlin](access-graph-gremlin-sessions.md) il [riferimento alla TinkerPop sessione](https://tinkerpop.apache.org/docs/current/reference/#console-sessions). ## Transazioni Neptune apre una nuova transazione all'inizio di ogni attraversamento Gremlin e chiude la transazione dopo il completamento dell'attraversamento. La transazione viene ripristinata quando si verifica un errore. Una singola transazione include più istruzioni separate da un punto e virgola (`;`) o un carattere nuova riga (`\n`). Ogni istruzione diversa dall'ultima deve terminare con una fase `next()` da eseguire. Vengono restituiti solo i dati di attraversamento finali. La logica di transazione manuale che utilizza `tx.commit()` e `tx.rollback()` non è supportata. **Importante** Si applica ***solo*** ai metodi dove invii la query Gremlin come ***stringa di testo*** (vedi [Transazioni Gremlin](access-graph-gremlin-transactions.md)). ## Vertice e spigolo IDs Neptune Gremlin Vertex e Edge devono essere di tipo. IDs `String` Queste stringhe di ID supportano i caratteri Unicode e non possono superare i 55 MB di dimensione. IDs I dati forniti dall'utente sono supportati, ma sono opzionali in caso di utilizzo normale. Se non si fornisce un ID quando si aggiunge un vertice o un arco, Neptune genera un UUID e lo converte in una stringa, in un formato simile al seguente: `"48af8178-50ce-971a-fc41-8c9a954cea62"`. Questi UUIDs non sono conformi allo standard RFC, quindi se avete bisogno di uno standard UUIDs dovreste generarli esternamente e fornirli quando aggiungete vertici o spigoli. **Nota** Il comando `Load` Neptune richiede che tu IDs fornisca, utilizzando **il** campo \$1id nel formato Neptune CSV. ## Fornito dall'utente IDs I prodotti forniti dall'utente IDs sono consentiti in Neptune Gremlin con le seguenti condizioni. + IDs I prodotti forniti sono opzionali. + Sono supportati solo i vertici e gli edge. + È supportato solo il tipo `String`. Per creare un nuovo vertice con un ID personalizzato, utilizza la fase `property` con la parola chiave `id`: `g.addV().property(id, 'customid')`. **Nota** Non mettere tra virgolette la parola chiave `id`. Si riferisce a `T.id`. Tutti i vertici IDs devono essere unici e tutti gli spigoli IDs devono essere unici. Tuttavia, Neptune consente che un vertice e un arco abbiano lo stesso ID. Se si tenta di creare un nuovo vertice utilizzando `g.addV()` e un vertice con tale ID esiste già, l'operazione non va a buon fine. Fa eccezione il caso in cui si specifica una nuova etichetta per il vertice; in tal caso l'operazione viene eseguita correttamente, ma aggiunge al vertice esistente la nuova etichetta e le eventuali proprietà aggiuntive specificate. Nessun elemento viene sovrascritto. Non viene creato un nuovo vertice. L'ID del vertice non cambia e rimane univoco. Ad esempio, i comandi della console Gremlin riportato di seguito, hanno esito positivo: ``` gremlin> g.addV('label1').property(id, 'customid') gremlin> g.addV('label2').property(id, 'customid') gremlin> g.V('customid').label() ==>label1::label2 ``` ## Proprietà Vertex IDs IDs Le proprietà Vertex vengono generate automaticamente e possono essere visualizzate come numeri positivi o negativi quando vengono richieste. ## Cardinalità delle proprietà dei vertici Neptune supporta la cardinalità di un insieme e la cardinalità singola. Se non è specificato, è impostata la cardinalità di un insieme. In questo modo, se imposti un valore di proprietà, questo aggiunge un nuovo valore alla proprietà, ma solo se non compare già nell'insieme dei valori. Questo è il valore di enumerazione Gremlin di [Set](https://tinkerpop.apache.org/javadocs/3.7.2/core/org/apache/tinkerpop/gremlin/structure/VertexProperty.Cardinality.html). `List` non è supportato. Per ulteriori informazioni sulla cardinalità delle proprietà, consultate l'argomento [Vertex](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...-) nel Gremlin. JavaDoc ## Aggiornamento della proprietà di un vertice Per aggiornare un valore di proprietà senza aggiungere un ulteriore valore all'insieme dei valori, specificare la cardinalità `single` nella fase `property`. ``` g.V('exampleid01').property(single, 'age', 25) ``` Questo consente di rimuovere tutti i valori esistenti della proprietà. ## Etichette Neptune supporta più etichette per un vertice. Quando crei un'etichetta, puoi specificare più etichette separandole con `::`. Ad esempio, `g.addV("Label1::Label2::Label3")` aggiunge un vertice con tre etichette diverse. La fase `hasLabel` corrisponde a questo vertice con una qualsiasi delle tre etichette: `hasLabel("Label1")` , `hasLabel("Label2")` e `hasLabel("Label3")`. **Importante** Il delimitatore `::` è riservato solo a quest'uso. Non è possibile specificare più etichette nella fase `hasLabel`. Ad esempio, `hasLabel("Label1::Label2")` non corrisponde a nulla. ## Caratteri escape Neptune risolve tutti i caratteri escape come descritto nella sezione [Escape dei caratteri speciali]( http://groovy-lang.org/syntax.html#_escaping_special_characters) della documentazione Apache Groovy Language. ## Limitazioni Groovy Neptune non supporta i comandi Groovy che non iniziano con `g`. Questo include la matematica (ad esempio: `1+1`), le chiamate di sistema (ad esempio: `System.nanoTime()`) e le definizioni delle variabili (ad esempio: `1+1`). **Importante** Neptune non supporta nomi di classe completi. Ad esempio, devi usare `single` e non `org.apache.tinkerpop.gremlin.structure.VertexProperty.Cardinality.single` nella richiesta Groovy. ## Serializzazione Neptune supporta le serializzazioni seguenti in base al tipo MIME richiesto. Neptune espone tutti i serializzatori TinkerPop che lo fanno, con il supporto per le varie versioni e configurazioni di GraphSon e. GraphBinary Nonostante siano presenti molte opzioni, la guida da utilizzare è semplice: + Se utilizzi driver Apache, preferisci l'impostazione predefinita per il TinkerPop driver senza specificarne uno in modo esplicito. A meno che non abbiate un motivo molto specifico per farlo, probabilmente non è necessario specificare il serializzatore nell'inizializzazione del driver. In generale, l'impostazione predefinita utilizzata dai driver è. `application/vnd.graphbinary-v1.0` + Se ti connetti a Neptune tramite HTTP, dai la priorità all'uso `application/vnd.gremlin-v3.0+json;types=false` di poiché i tipi incorporati nella versione alternativa di GraphSon 3 lo rendono complicato da usare. + In genere `application/vnd.graphbinary-v1.0-stringd` è utile solo se usato insieme a [Gremlin Console](https://docs.aws.amazon.com//neptune/latest/userguide/access-graph-gremlin-console.html) in quanto converte tutti i risultati in una rappresentazione di stringa per una semplice visualizzazione. + I formati rimanenti rimangono presenti per ragioni obsolete e in genere non dovrebbero essere utilizzati con i driver senza una chiara causa. | | | | | --- |--- |--- | | Tipo MIME | Serializzazione | Configurazione | | `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(funziona solo con 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 | | **Nota** La tabella dei serializzatori mostrata qui si riferisce alla denominazione a partire dalla versione 3.7.0. TinkerPop [Se desideri saperne di più su questa modifica, consulta la documentazione di aggiornamento. TinkerPop ](https://tinkerpop.apache.org/docs/current/upgrade/#_serializer_renaming) Il supporto per la serializzazione Gryo era obsoleto nella versione 3.4.3 ed è stato rimosso ufficialmente nella versione 3.6.0. Se state usando Gryo in modo esplicito o su una versione del driver che lo utilizza di default, allora dovreste passare al driver o aggiornarlo. GraphBinary ## Passaggi Lambda Neptune non supporta i passaggi Lambda. ## Metodi Gremlin non supportati Neptune non supporta i metodi Gremlin seguenti: + `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)` Ad esempio, l'attraversamento seguente non è consentito: `g.V().addE('something').from(__.V().next()).to(__.V().next())`. **Importante** Si applica ***solo*** ai metodi dove invii la query Gremlin come ***stringa di testo***. ## Passaggi Gremlin non supportati Neptune non supporta i passaggi Gremlin seguenti: + Il [passaggio io( )](http://tinkerpop.apache.org/docs/3.7.2/reference/#io-step) Gremlin è supportata solo parzialmente in Neptune. Può essere usata in un contesto di lettura, come in `g.io((url)).read()`, ma non in un contesto di scrittura. ## Caratteristiche del grafo Gremlin in Neptune L'implementazione di Gremlin in Neptune non espone l'oggetto `graph`. Le tabelle seguenti elencano le caratteristiche di Gremlin e indicano se Neptune le supporta o meno. ### Supporto di Neptune delle funzionalità di `graph` Le caratteristiche del grafo Neptune, se supportate, sono le stesse di quelle restituite dal comando `graph.features()`. | | | Caratteristica del grafo | Abilitata? | | --- |--- | | Transactions | true | | ThreadedTransactions | false | | Computer | false | | Persistence | true | | ConcurrentAccess | true | ### Supporto di Neptune delle funzionalità della variabile | | | Caratteristica della variabile | Abilitata? | | --- |--- | | 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 | ### Supporto di Neptune delle caratteristiche del vertice | | | Caratteristica del vertice | Abilitata? | | --- |--- | | 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 | ### Supporto di Neptune delle caratteristiche della proprietà del vertice | | | Caratteristica della proprietà del vertice | Abilitata? | | --- |--- | | 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 | ### Supporto di Neptune delle caratteristiche dell'arco | | | Caratteristica dell'arco | Abilitata? | | --- |--- | | AddEdges | true | | RemoveEdges | true | | UserSuppliedIds | true | | AddProperty | true | | RemoveProperty | true | | NumericIds | false | | StringIds | true | | UuidIds | false | | CustomIds | false | | AnyIds | false | ### Supporto di Neptune delle caratteristiche della proprietà dell'arco | | | Caratteristica della proprietà dell'arco | Abilitata? | | --- |--- | | 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 | # Conformità agli standard SPARQL in Amazon Neptune Dopo aver elencato gli standard SPARQL applicabili, le seguenti sezioni forniscono dettagli specifici su come l'implementazione SPARQL di Neptune si estende o si discosta da tali standard. **Topics** + [Standard applicabili per SPARQL](#feature-sparql-applicable-standards) + [Prefissi dello spazio dei nomi predefiniti in Neptune SPARQL](#sparql-default-prefixes) + [Grafo predefinito SPARQL e grafi denominati](#sparql-default-graph) + [Funzioni del XPath costruttore SPARQL supportate da Neptune](#access-graph-sparql-xpath-constructors) + [IRI di base predefinito per query e aggiornamenti](#opencypher-compliance-default-iri) + [Valori xsd:dateTime in Neptune](#access-graph-sparql-xsd-date-time) + [Gestione di Neptune dei valori speciali a virgola mobile](#feature-overview-special-values-comparisons) + [Limitazione di Neptune dei valori di lunghezza arbitraria](#feature-overview-arbitrary-length-values) + [Neptune estende il confronto di uguaglianza in SPARQL](#feature-overview-sparql-not-equal) + [Gestione dei Out-of-Range valori letterali in Neptune SPARQL](#feature-overview-sparql-out-of-range) Amazon Neptune è conforme ai seguenti standard nell'implementazione del linguaggio di query a grafo SPARQL. ## Standard applicabili per SPARQL + SPARQL è definito dalla raccomandazione W3C [SPARQL 1.1 Query Language](https://www.w3.org/TR/sparql11-query/) del 21 marzo 2013. + Il protocollo SPARQL Update e il linguaggio di query sono definiti dalla specifica W3C di [SPARQL 1.1 Update](https://www.w3.org/TR/sparql11-update/). + Per i formati numerici, SPARQL segue la specifica [W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes](https://www.w3.org/TR/xmlschema11-2/) conforme alla specifica IEEE 754 ([IEEE 754-2019 - IEEE Standard for Floating-Point Arithmetic](https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html). Per ulteriori informazioni, vedi anche la [pagina di Wikipedia IEEE 754](https://en.wikipedia.org/wiki/IEEE_754)). Tuttavia, le funzionalità introdotte dopo la versione `IEEE 754-1985` non sono incluse nella specifica. ## Prefissi dello spazio dei nomi predefiniti in Neptune SPARQL Neptune definisce i seguenti prefissi per impostazione predefinita per l'utilizzo nelle query SPARQL. Per ulteriori informazioni, vedere [Prefixed Names](https://www.w3.org/TR/sparql11-query/#prefNames) (Nomi con prefisso) nella specifica SPARQL. + `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#` ## Grafo predefinito SPARQL e grafi denominati Amazon Neptune associa ogni tripla a un grafo denominato. Il grafo predefinito è definito come l'unione di grafi denominati. **Grafico predefinito per query** Se invii una query SPARQL senza specificare un grafo in maniera esplicita tramite la parola chiave `GRAPH` o costrutti quali `FROM NAMED`, Neptune considera sempre tutte le triple nell'istanza database. Ad esempio, la seguente query restituisce tutte le triple da un endpoint SPARQL Neptune: `SELECT * WHERE { ?s ?p ?o }` Le triple che appaiono in più grafici vengono restituite una sola volta. Per informazioni sulla specifica del grafico predefinito, consulta la sezione [RDF Dataset](https://www.w3.org/TR/sparql11-query/#rdfDataset) delle specifiche SPARQL 1.1 Query Language. **Specifica del grafo denominato per caricamento, inserimenti o aggiornamenti** Se non specifichi un grafo denominato durante il caricamento, l'inserimento o l'aggiornamento di triple, Neptune utilizza il grafo denominato di fallback definito dall'URI `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`. Quando invii una richiesta `Load` Neptune utilizzando un formato basato sulla tripla, puoi specificare il grafo nominato da utilizzare per tutte le triple utilizzando il parametro `parserConfiguration: namedGraphUri`. Per ulteriori informazioni sulla sintassi del comando `Load`, consulta [Comando dello strumento di caricamento Neptune](load-api-reference-load.md). **Importante** Se non utilizzi questo parametro e non specifichi un grafo denominato, viene utilizzato l'URI di fallback: `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`. Questo grafo di fallback denominato viene anche utilizzato se carichi triple tramite `SPARQL UPDATE` senza fornire in maniera esplicita una destinazione del grafo denominato. Puoi utilizzare il formato basato su quadruple N-Quads per specificare un grafo denominato per ogni tripla nel database. **Nota** Utilizzare N-Quads consente di lasciare il grafo denominato vuoto. In questo caso, viene utilizzato `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`. Puoi sostituire il grafo denominato predefinito per N-Quads utilizzando l'opzione di configurazione parser `namedGraphUri`. ## Funzioni del XPath costruttore SPARQL supportate da Neptune Lo standard SPARQL consente ai motori SPARQL di supportare un set estensibile di funzioni di costruzione. XPath Neptune attualmente supporta le seguenti funzioni costruttore, dove il prefisso `xsd` è definito come `http://www.w3.org/2001/XMLSchema#`: + `xsd:boolean` + `xsd:integer` + `xsd:double` + `xsd:float` + `xsd:decimal` + `xsd:long` + `xsd:unsignedLong` ## IRI di base predefinito per query e aggiornamenti Poiché un cluster Neptune ha diversi endpoint, l'utilizzo dell'URL di richiesta di una query o di un aggiornamento come IRI di base potrebbe portare a risultati imprevisti durante la risoluzione relativa. IRIs A partire dal [rilascio 1.2.1.0 del motore](engine-releases-1.2.1.0.md), Neptune utilizza `http://aws.amazon.com/neptune/default/` come IRI di base se un IRI di base esplicito non fa parte della richiesta. Nella richiesta seguente, l'IRI di base fa parte della richiesta: ``` BASE INSERT DATA { "n1" } BASE SELECT * { ?p ?o } ``` E il risultato sarà: ``` ?p ?o http://example.org/default/id n1 ``` In questa richiesta, tuttavia, non è incluso alcun IRI di base: ``` INSERT DATA { "n1" } SELECT * { ?p ?o } ``` In tal caso, il risultato sarà: ``` ?p ?o http://aws.amazon.com/neptune/default/id n1 ``` ## Valori xsd:dateTime in Neptune Per motivi di prestazioni, Neptune date/time memorizza sempre i valori come Coordinated Universal Time (UTC). Questo rende i confronti diretti molto efficienti. Ciò significa anche che se si immette un valore `dateTime` che specifica un particolare fuso orario, Neptune converte il valore in formato UTC ed elimina le informazioni sul fuso orario. Quindi, quando si recupera il valore `dateTime` in un secondo momento, viene espresso in formato UTC, non l'ora del fuso orario originale e non è più possibile risalire al fuso orario originale. ## Gestione di Neptune dei valori speciali a virgola mobile Neptune gestisce i valori speciali a virgola mobile in SPARQL nel seguente modo: ### Gestione del valore NaN di SPARQL in Neptune In Neptune, SPARQL può accettare un valore `NaN` in una query. Non viene fatta alcuna distinzione tra valori `NaN` di segnalazione e silenziosi. Neptune considera tutti i valori `NaN` come silenziosi. Dal punto di vista semantico, non è possibile un confronto di un valore `NaN` poiché non esistono elementi maggiori di, minori di o uguali a un valore `NaN`. Ciò significa che un valore `NaN` su un lato di un confronto in teoria non corrisponde mai a *qualcosa* sull'altro lato. Tuttavia, la [specifica XSD](https://www.w3.org/TR/xmlschema-2/#double) considera due valori `NaN` `xsd:double` o `xsd:float` come valori uguali. Neptune segue questo principio per il filtro `IN`, per l'operatore equal nelle espressioni di filtro e per la semantica di corrispondenza esatta (avendo un valore `NaN` nella posizione dell'oggetto di un modello di tripla). ### Gestione del valore infinito di SPARQL in Neptune In Neptune, SPARQL può accettare un valore `INF` o `-INF` in una query. `INF` viene confrontato come maggiore di qualsiasi altro valore numerico e `-INF` viene confrontato come minore di qualsiasi altro valore numerico. Due valori INF con segni corrispondenti si confrontano come uguali tra loro indipendentemente dal loro tipo (ad esempio, un float `-INF` confronta come uguale a un doppio `-INF`). Non è possibile un confronto con un valore `NaN` ovviamente poiché non esistono elementi maggiori di, minori di o uguali a un valore `NaN`. ### Gestione dello zero negativo di SPARQL in Neptune Neptune normalizza un valore zero negativo a uno zero senza segno. È possibile utilizzare i valori zero negativo in una query, ma non vengono registrati come tali nel database e vengono confrontati come uguali a zero senza segno. ## Limitazione di Neptune dei valori di lunghezza arbitraria Neptune limita la dimensione di archiviazione dei valori interi XSD, dei valori a virgola mobile e dei valori decimali in SPARQL a 64 bit. L'utilizzo di valori più grandi genera un errore `InvalidNumericDataException`. ## Neptune estende il confronto di uguaglianza in SPARQL Lo standard SPARQL definisce una logica ternaria per le espressioni di valore, in cui un'espressione di valore può restituire `true`, `false`, o `error`. La semantica predefinita per l'uguaglianza dei termini definita nella [specifica SPARQL 1.1](https://www.w3.org/TR/sparql11-query/#func-RDFterm-equal), che si applica ai confronti `=` e `!=` nelle condizioni `FILTER`, produce un `error` quando si confrontano tipi di dati che non sono esplicitamente comparabili nella [tabella degli operatori](https://www.w3.org/TR/sparql11-query/#OperatorMapping) nella specifica. Questo comportamento può portare a risultati non intuitivi, come nell'esempio seguente. Dati: ``` "127.0.0.1"^^ ``` Query 1: ``` SELECT * WHERE { ?o . FILTER(?o = "127.0.0.2"^^) } ``` Query 2: ``` SELECT * WHERE { ?o . FILTER(?o != "127.0.0.2"^^) } ``` Con la semantica SPARQL predefinita utilizzata da Neptune prima del rilascio 1.0.2.1, entrambe le query restituiranno il risultato vuoto. Il motivo è che `?o = "127.0.0.2"^^` quando viene valutato per `?o := "127.0.0.1"^^`, produce un `error` anziché `false` perché non esistono regole di confronto esplicite specificate per il tipo di dati personalizzato ``. Di conseguenza, anche la versione negata nella seconda query produce un `error`. In entrambe le query, l'`error` causa il filtraggio della soluzione candidata. A partire dal rilascio 1.0.2.1, Neptune ha esteso l'operatore di disuguaglianza SPARQL in accordo con le specifiche. Vedere la [sezione SPARQL 1.1 sull'estensibilità dell'operatore](https://www.w3.org/TR/sparql11-query/#operatorExtensibility), che consente ai motori di definire regole aggiuntive su come eseguire il confronto tra tipi di dati incorporati definiti dall'utente e non comparabili. Utilizzando questa opzione, Neptune ora tratta un confronto di due tipi di dati che non è esplicitamente definito nella tabella di mappatura dell'operatore come se restituisse `true`, se i valori letterali e i tipi di dati sono sintatticamente uguali, altrimenti, false. In ogni caso, non viene prodotto un `error`. Usando queste nuove semantiche, la seconda query restituirebbe `"127.0.0.1"^^` invece di un risultato vuoto. ## Gestione dei Out-of-Range valori letterali in Neptune SPARQL La semantica XSD definisce ogni tipo numerico con il suo spazio valore, ad eccezione di `integer` e `decimal`. Queste definizioni limitano ogni tipo a un intervallo di valori. Ad esempio, l'intervallo di un intervallo `xsd:byte` è compreso tra -128 e \$1127, inclusi. Qualsiasi valore al di fuori di questo intervallo è considerato non valido. Se si tenta di assegnare un valore letterale al di fuori dello spazio dei valori di un tipo (ad esempio, se si tenta di impostare an su un `xsd:byte` valore letterale di 999), Neptune accetta il valore così com'è, senza arrotondarlo o out-of-range troncarlo. Ma non lo mantiene come valore numerico perché il tipo fornito non può rappresentarlo. Cioè, Neptune accetta `"999"^^xsd:byte` anche se è un valore al di fuori dell'intervallo di valori `xsd:byte` definito. Tuttavia, dopo che il valore viene mantenuto nel database, può essere utilizzato solo nella semantica di corrispondenza esatta, in una posizione oggetto di un modello triplo. Nessun filtro di intervallo può essere eseguito su di esso perché i valori letterali non vengono trattati come valori numerici. out-of-range La specifica SPARQL 1.1 definisce gli [operatori di intervallo](https://www.w3.org/TR/sparql11-query/#OperatorMapping) nel formato `numeric`*-operator-*`numeric`, `string`*-operator-*`string`, `literal`*-operator-*`literal` e così via. Neptune non può eseguire un operatore di confronto di intervalli simile a `invalid-literal`*-operator-*`numeric-value`. # Conformità alle specifiche OpenCypher in Amazon Neptune Il rilascio di Amazon Neptune di openCypher supporta generalmente le clausole, gli operatori, le espressioni, le funzioni e la sintassi definiti nella specifica openCypher corrente, ovvero [Cypher Query Language Reference versione 9](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf). Le limitazioni e le differenze nel supporto di Neptune per openCypher sono indicate di seguito. Amazon Neptune supporta anche diverse funzionalità oltre all'ambito delle specifiche OpenCypher. Fare riferimento a [Estensioni OpenCypher in Amazon Neptune](access-graph-opencypher-extensions.md) per ulteriori dettagli. **Nota** L'attuale implementazione Neo4j di Cypher contiene funzionalità che non sono contenute nella specifica openCypher menzionata sopra. Se stai migrando il codice Cypher corrente a Neptune, consulta [Compatibilità di Neptune con Neo4j](migration-compatibility.md) e [Riscrittura delle query Cypher da eseguire in openCypher su Neptune](migration-opencypher-rewrites.md) per ulteriori informazioni. ## Supporto delle clausole openCypher in Neptune Neptune supporta le seguenti clausole, ad eccezione di quanto indicato: + `MATCH`: supportata, ad eccezione di *`shortestPath()`* e *`allShortestPaths()`* che non sono attualmente supportate. + `OPTIONAL MATCH` + *`MANDATORY MATCH`*: **non** è attualmente supportata in Neptune. Neptune, tuttavia, supporta [valori ID personalizzati](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids) nelle query `MATCH`. + `RETURN`: supportata, tranne quando viene utilizzata con valori non statici per `SKIP`o `LIMIT`. Ad esempio, quanto segue attualmente non funziona: ``` MATCH (n) RETURN n LIMIT toInteger(rand()) // Does NOT work! ``` + `WITH`: supportata, tranne quando viene utilizzata con valori non statici per `SKIP`o `LIMIT`. Ad esempio, quanto segue attualmente non funziona: ``` 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`: Neptune consente di creare [valori ID personalizzati](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids) nelle query `CREATE`. + `DELETE` + `SET` + `REMOVE` + `MERGE`: Neptune supporta [valori ID personalizzati](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids) nelle query `MERGE`. + *`CALL[YIELD...]`*: **non** è attualmente supportata in Neptune. + `UNION, UNION ALL`: le query di sola lettura sono supportate, ma le query di mutazione **non** sono attualmente supportate. + `USING`[— `USING` è supportato dalla versione 1.3.2.0 del motore.](https://docs.aws.amazon.com//neptune/latest/userguide/engine-releases-1.3.2.0.html) Per ulteriori informazioni, vedere [Query hints](https://docs.aws.amazon.com//neptune/latest/userguide/opencypher-query-hints.html). ## Supporto degli operatori openCypher in Neptune Neptune supporta i seguenti operatori, ad eccezione di quanto indicato: **Operatori generali** + `DISTINCT` + Operatore `.` per accedere alle proprietà di una mappa letterale annidata. **Operatori matematici** + Operatore di addizione `+`. + Operatore di sottrazione `-`. + Operatore di moltiplicazione `*`. + Operatore di divisione `/`. + Operatore di divisione modulo `%`. + L'operatore `^` di esponenziazione. *is NOT supported* **Operatori di confronto** + Operatore di addizione `=`. + Operatore di disuguaglianza `<>`. + L'operatore minore di `<` è supportato tranne quando uno degli argomenti è un percorso, un elenco o una mappa. + L'operatore maggiore di `>` è supportato tranne quando uno degli argomenti è un percorso, un elenco o una mappa. + L'operatore `<=` less-than-or-equal -to è supportato tranne quando uno degli argomenti è Path, List o Map. + L'operatore `>=` greater-than-or-equal -to è supportato tranne quando uno degli argomenti è Path, List o Map. + `IS NULL` + `IS NOT NULL` + `STARTS WITH` è supportato se i dati da cercare sono una stringa. + `ENDS WITH` è supportato se i dati da cercare sono una stringa. + `CONTAINS` è supportato se i dati da cercare sono una stringa. **Operatori booleani** + `AND` + `OR` + `XOR` + `NOT` **Operatori di stringa** + Operatore di concatenazione `+`. **Operatori di elenco** + Operatore di concatenazione `+`. + `IN` (verifica la presenza di un elemento nell'elenco) ## Supporto delle espressioni openCypher in Neptune Neptune supporta le seguenti espressioni, ad eccezione di quanto indicato: + `CASE` + L'espressione `[]` **non** è attualmente supportata in Neptune per l'accesso alle chiavi di proprietà calcolate dinamicamente all'interno di un nodo, una relazione o una mappa. Ad esempio, quanto segue non funziona: ``` MATCH (n) WITH [5, n, {key: 'value'}] AS list RETURN list[1].name ``` ## Supporto delle funzioni openCypher in Neptune Neptune supporta le seguenti funzioni, ad eccezione di quanto indicato: **Funzioni di predicato** + `exists()` **Funzioni scalari** + `coalesce()` + `endNode()` + `epochmillis()` + `head()` + `id()` + `last()` + `length()` + `randomUUID()` + `properties()` + `removeKeyFromMap` + `size()`: questo metodo di overload attualmente funziona solo per espressioni di modelli, elenchi e stringhe + `startNode()` + `timestamp()` + `toBoolean()` + `toFloat()` + `toInteger()` + `type()` **Funzioni di aggregazione** + `avg()` + `collect()` + `count()` + `max()` + `min()` + `percentileDisc()` + `stDev()` + `percentileCont()` + `stDevP()` + `sum()` **Elencare le funzioni** + [`join()`](access-graph-opencypher-extensions.md#opencypher-compliance-join-function) (concatena le stringhe di un elenco in un'unica stringa) + `keys()` + `labels()` + `nodes()` + `range()` + `relationships()` + `reverse()` + `tail()` **Funzioni matematiche – numeriche** + `abs()` + `ceil()` + `floor()` + `rand()` + `round()` + `sign()` **Funzioni matematiche – logaritmiche** + `e()` + `exp()` + `log()` + `log10()` + `sqrt()` **Funzioni matematiche – trigonometriche** + `acos()` + `asin()` + `atan()` + `atan2()` + `cos()` + `cot()` + `degrees()` + `pi()` + `radians()` + `sin()` + `tan()` **Funzioni stringa** + [`join()`](access-graph-opencypher-extensions.md#opencypher-compliance-join-function) (concatena le stringhe di un elenco in un'unica stringa) + `left()` + `lTrim()` + `replace()` + `reverse()` + `right()` + `rTrim()` + `split()` + `substring()` + `toLower()` + `toString()` + `toUpper()` + `trim()` **Funzioni definite dall'utente** *User-defined functions***non** sono attualmente supportati in Neptune. ## Dettagli sull'implementazione di openCypher specifici per Neptune Le sezioni seguenti descrivono i modi in cui l'implementazione di openCypher in Neptune può differire o andare oltre la [specifica openCypher](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf). ### Valutazioni di percorsi a lunghezza variabile (VLP) in Neptune Le valutazioni dei percorsi a lunghezza variabile (`VLP`) rilevano i percorsi tra i nodi del grafo. La lunghezza del percorso può essere illimitata in una query. Per evitare cicli, la [specifica openCypher](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf) specifica che ogni arco deve essere attraversato al massimo una volta per soluzione. Infatti VLPs, l'implementazione di Neptune si discosta dalla specifica OpenCypher in quanto supporta solo valori costanti per i filtri di uguaglianza delle proprietà. Eseguire la seguente query: ``` MATCH (x)-[:route*1..2 {dist:33, code:x.name}]->(y) return x,y ``` Poiché il valore del filtro di uguaglianza della proprietà `x.name` non è una costante, questa query restituisce l'eccezione `UnsupportedOperationException` con il messaggio: `Property predicate over variable-length relationships with non-constant expression is not supported in this release.` ### Supporto temporale nell'implementazione di Neptune OpenCypher (database Neptune 1.3.1.0 e versioni successive) Neptune attualmente fornisce un supporto limitato per la funzione temporale in openCypher. Supporta il tipo di dati `DateTime` per i tipi temporali. La funzione `datetime()` può essere utilizzata per ottenere la data e l'ora UTC correnti in questo modo: ``` RETURN datetime() as res ``` I valori di data e ora possono essere analizzati da stringhe in formato `"`*date*`T`*time*`"` in cui *data* e *ora* sono entrambe espresse in uno dei formati supportati di seguito: **Formati di data supportati** + `yyyy-MM-dd` + `yyyyMMdd` + `yyyy-MM` + `yyyy-DDD` + `yyyyDDD` + `yyyy` **Formati di ora supportati** + `HH:mm:ssZ` + `HHmmssZ` + `HH:mm:ssZ` + `HH:mmZ` + `HHmmZ` + `HHZ` + `HHmmss` + `HH:mm:ss` + `HH:mm` + `HHmm` + `HH` Esempio: ``` RETURN datetime('2022-01-01T00:01') // or another example: RETURN datetime('2022T0001') ``` Nota che tutti i date/time valori in Neptune OpenCypher vengono archiviati e recuperati come valori UTC. Neptune openCypher utilizza un orologio `statement`, il che significa che lo stesso istante di tempo viene utilizzato per tutta la durata di una query. Una query diversa all'interno della stessa transazione può utilizzare un istante di tempo diverso. Neptune non supporta l'uso di una funzione all'interno di una chiamata a `datetime()`. Ad esempio, quanto segue non funziona: ``` CREATE (:n {date:datetime(tostring(2021))}) // ---> NOT ALLOWED! ``` Neptune supporta la funzione `epochmillis()` che converte `datetime` in `epochmillis`. Esempio: ``` MATCH (n) RETURN epochMillis(n.someDateTime) 1698972364782 ``` Neptune attualmente non supporta altre funzioni e operazioni sugli oggetti `DateTime`, come l'addizione e la sottrazione. ### Supporto temporale nell'implementazione di Neptune OpenCypher (Neptune Analytics e Neptune Database 1.3.2.0 e versioni successive) La seguente funzionalità datetime OpenCypher si applica a Neptune Analytics. In alternativa, è possibile utilizzare il parametro labmode `DatetimeMillisecond=enabled` per abilitare la seguente funzionalità datetime nella versione 1.3.2.0 e successive del motore Neptune. Per maggiori dettagli sull'utilizzo di questa funzionalità in labmode, consulta. [Supporto datetime esteso](features-lab-mode.md#labmode-extended-datetime-support) + Support per millisecondi. Il valore letterale Datetime verrà sempre restituito in millisecondi, anche se i millisecondi sono 0. (Il comportamento precedente consisteva nel troncare i millisecondi.) ``` 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 per chiamare la funzione datetime () su proprietà memorizzate o risultati intermedi. Ad esempio, le seguenti interrogazioni non erano possibili prima di questa funzionalità. Datetime () sulle proprietà: ``` // 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 () su risultati intermedi: ``` // Parse datetime from parameter UNWIND $list as myDate RETURN datetime(myDate) as d ``` + Ora è anche possibile salvare le proprietà datetime che vengono create nei casi sopra menzionati. Salvare datetime dalla proprietà string di una proprietà a un'altra: ``` // 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) ``` Batch crea nodi da un parametro con una proprietà datetime: ``` // 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 per un sottoinsieme più ampio di formati ISO8601 datetime. Consulta qui di seguito. Formati supportati Il formato di un valore datetime è [Date] T [Time] [Timezone], dove T è il separatore. Se non viene fornito un fuso orario esplicito, si presume che UTC (Z) sia l'impostazione predefinita. Fuso orario I formati di fuso orario supportati sono: + \$1/-HH: mm + \$1/-HHmm + \$1/-H La presenza di un fuso orario in una stringa datetime è facoltativa. Se l'offset del fuso orario è 0, è possibile utilizzare Z al posto del suffisso del fuso orario riportato sopra per indicare l'ora UTC. L'intervallo supportato di un fuso orario va da - 14:00 a \$1 14:00. Data Se non è presente alcun fuso orario o se il fuso orario è UTC (Z), i formati di data supportati sono i seguenti: **Nota** DDD si riferisce a una data ordinale, che rappresenta un giorno dell'anno compreso tra 001 e 365 (366 negli anni bisestili). Ad esempio, 2024-002 rappresenta il 2 gennaio 2024. + `yyyy-MM-dd` + `yyyyMMdd` + `yyyy-MM` + `yyyyMM` + `yyyy-DDD` + `yyyyDDD` + `yyyy` Se viene scelto un fuso orario diverso da Z, i formati di data supportati sono limitati ai seguenti: + `yyyy-MM-dd` + `yyyy-DDD` + `yyyyDDD` L'intervallo di date supportato va dal 1400-01-01 al 9999-12-31. Orario Se non è presente alcun fuso orario o se il fuso orario è UTC (Z), i formati di ora supportati sono: + `HH:mm:ss.SSS` + `HH:mm:ss` + `HHmmss.SSS` + `HHmmss` + `HH:mm` + `HHmm` + `HH` Se viene scelto un fuso orario diverso da Z, i formati di ora supportati sono limitati ai seguenti: + `HH:mm:ss` + `HH:mm:ss.SSS` ### Differenze nella semantica del linguaggio openCypher di Neptune Neptune rappresenta il nodo e la IDs relazione come stringhe anziché numeri interi. L'ID è uguale all'ID fornito tramite lo strumento di caricamento in blocco di dati. Se esiste uno spazio dei nomi per la colonna, lo spazio dei nomi più l'ID. Di conseguenza, la funzione `id` restituisce una stringa anziché un numero intero. Il tipo di dati `INTEGER` è limitato a 64 bit. Quando si convertono valori a virgola mobile o stringa più grandi in un numero intero utilizzando la funzione `TOINTEGER`, i valori negativi vengono troncati a `LLONG_MIN` e i valori positivi vengono troncati a `LLONG_MAX`. Esempio: ``` RETURN TOINTEGER(2^100) > 9223372036854775807 RETURN TOINTEGER(-1 * 2^100) > -9223372036854775808 ``` ### Proprietà multivalore Sebbene OpenCypher CREATE non crei proprietà multivalore, possono esistere nei dati creati utilizzando Gremlin (Neptune Database) o durante il caricamento dei dati (Neptune Database e Neptune Analytics). Se Neptune openCypher incontra una proprietà multivalore, uno dei valori viene scelto arbitrariamente, creando un risultato non deterministico. ### Gestione dei valori NaN La gestione da parte di Neptune del confronto dei valori delle `NaN` proprietà non è definita. Basarsi su tali confronti può portare a risultati inaspettati o non deterministici.