Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Remarques sur la conformité d'Amazon Neptune avec les normes
Amazon Neptune est conforme aux normes applicables à l'implémentation des langages de requête de graphe Gremlin et SPARQL dans la plupart des cas.
Ces sections décrivent les normes, ainsi que les domaines où Neptune étend ces normes ou diverge de celles-ci.
**Topics**
+ [Conformité d'Amazon Neptune avec les normes Gremlin](access-graph-gremlin-differences.md)
+ [Conformité d'Amazon Neptune avec les normes SPARQL](feature-sparql-compliance.md)
+ [Conformité aux spécifications OpenCypher dans Amazon Neptune](feature-opencypher-compliance.md)
# Conformité d'Amazon Neptune avec les normes Gremlin
Les sections suivantes fournissent une vue d'ensemble de l'implémentation Neptune de Gkremlin et de ses différences par rapport à l'implémentation Apache. TinkerPop
Neptune implémente certaines étapes de Gkremlin de manière native dans son moteur et utilise l'implémentation d'Apache TinkerPop Gkremlin pour en traiter d'autres (voir). [Prise en charge des étapes Gremlin natives dans Amazon Neptune](gremlin-step-support.md)
**Note**
Pour obtenir des exemples concrets de ces différences implémentation dans la console Gremlin et dans Amazon Neptune, consultez la section [Utilisation de Gkremlin pour accéder aux données graphiques dans Amazon Neptune](get-started-graph-gremlin.md) du Quick Start.
**Topics**
+ [Normes applicables pour Gremlin](#feature-gremlin-applicable-standards)
+ [Variables et paramètres dans les scripts](#feature-gremlin-differences-variables)
+ [TinkerPop énumérations](#feature-gremlin-differences-tinkerpop)
+ [Code Java](#feature-gremlin-differences-java)
+ [Propriétés des éléments](#feature-gremlin-differences-properties-on-elements)
+ [Exécution de script](#feature-gremlin-differences-script)
+ [Séances](#feature-gremlin-differences-sessions)
+ [Transactions](#feature-gremlin-differences-transactions)
+ [Vertex et arête IDs](#feature-gremlin-differences-vertex-edge-ids)
+ [Fourni par l'utilisateur IDs](#feature-gremlin-differences-user-supplied-ids)
+ [Propriété Vertex IDs](#feature-gremlin-differences-vertex-property-ids)
+ [Cardinalité des propriétés de sommet](#feature-gremlin-differences-vertex-property-cardinality)
+ [Mise à jour d'une propriété de sommet](#feature-gremlin-differences-vertex-property-update)
+ [Étiquettes](#feature-gremlin-differences-labels)
+ [Caractères d'échappement](#feature-gremlin-differences-escapes)
+ [Limites Groovy](#feature-gremlin-differences-groovy)
+ [Sérialisation](#feature-gremlin-differences-serialization)
+ [Étapes Lambda](#feature-gremlin-differences-lambda)
+ [Méthodes Gremlin non prises en charge](#feature-gremlin-differences-unsupported-methods)
+ [Étapes Gremlin non prises en charge](#feature-gremlin-differences-unsupported-steps)
+ [Fonctionnalités du graphe Gremlin dans Neptune](#gremlin-api-reference-features)
## Normes applicables pour Gremlin
+ Le langage G705 est défini par la [ TinkerPop documentation Apache](http://tinkerpop.apache.org/docs/current/reference/) et l' TinkerPop implémentation Apache de G705 plutôt que par une spécification formelle.
+ Pour les formats numériques, Gremlin suit la norme IEEE 754 ([IEEE 754-2019 - IEEE Standard for Floating-Point Arithmetic](https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html) ; voir aussi la [page Wikipedia sur IEEE 754](https://en.wikipedia.org/wiki/IEEE_754) pour plus d'informations).
## Variables et paramètres dans les scripts
En ce qui concerne les variables pré-liées, l'objet de traversée `g` est pré-lié dans Neptune, et l'objet `graph` n'est pas pris en charge.
Bien que Neptune ne prenne pas en charge les variables Gremlin ni le paramétrage dans des scripts, vous pouvez souvent rencontrer sur Internet des exemples de scripts contenant des déclarations de variables, tels que :
```
String query = "x = 1; g.V(x)";
List results = client.submit(query).all().get();
```
Il existe également de nombreux exemples qui utilisent le [paramétrage](https://tinkerpop.apache.org/docs/current/reference/#parameterized-scripts) (ou les liaisons) lors de la soumission de requêtes, tels que :
```
Map params = new HashMap<>();
params.put("x",1);
String query = "g.V(x)";
List results = client.submit(query).all().get();
```
Ces exemples de paramètres sont généralement associés à des avertissements sur les pénalités de performance possibles en cas de non-paramétrage lorsque cela est possible. Il existe de nombreux exemples de ce type TinkerPop que vous pouvez rencontrer, et ils semblent tous assez convaincants quant à la nécessité de paramétrer.
Cependant, les fonctionnalités de déclaration de variables et de paramétrage (ainsi que les avertissements) ne s'appliquent qu'au TinkerPop serveur Gremlin lorsqu'il utilise le. `GremlinGroovyScriptEngine` Elles ne s'appliquent pas lorsque le serveur Gremlin utilise la grammaire `gremlin-language` ANTLR de Gremlin pour analyser les requêtes. La grammaire ANTLR ne prend en charge ni les déclarations de variables ni le paramétrage. Ainsi, lorsque vous utilisez ANTLR, vous n'avez rien à craindre en cas de non-paramétrage. La grammaire ANTLR étant une composante plus récente TinkerPop, les anciens contenus que vous pouvez rencontrer sur Internet ne reflètent généralement pas cette distinction.
Neptune utilise la grammaire ANTLR dans son moteur de traitement des requêtes plutôt que le moteur `GremlinGroovyScriptEngine`. Il ne prend donc pas en charge les variables, le paramétrage ni la propriété `bindings`. Par conséquent, les problèmes potentiels liés au non-paramétrage ne s'appliquent pas dans Neptune. Avec Neptune, il est parfaitement sûr de soumettre simplement la requête telle quelle, alors que beaucoup la paramétrerait. Par conséquent, l'exemple précédent peut être simplifié sans aucune perte de performance comme suit :
```
String query = "g.V(1)";
List results = client.submit(query).all().get();
```
## TinkerPop énumérations
Neptune ne prend pas en charge les noms de classe complets pour les valeurs d'énumération. Par exemple, vous devez utiliser `single` et non `org.apache.tinkerpop.gremlin.structure.VertexProperty.Cardinality.single` dans votre demande Groovy.
Le type d'énumération est déterminé par le type de paramètre.
Le tableau suivant indique les valeurs d'énumération autorisées et le nom TinkerPop complet correspondant.
| Valeurs autorisées | 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. Barrière](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.Choisissez](https://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/process/traversal/Pick.html) |
## Code Java
Neptune ne prend pas en charge les appels à des méthodes définies par des appels arbitraires de bibliothèque Java ou Java autres que ceux pris en charge par Gremlin. APIs Par exemple, `java.lang.*`, `Date()` et `g.V().tryNext().orElseGet()` ne sont pas autorisés.
## Propriétés des éléments
Neptune ne prend pas en charge l'`materializeProperties`indicateur introduit dans la TinkerPop version 3.7.0 pour renvoyer les propriétés des éléments. Par conséquent, Neptune ne renverra toujours que les sommets ou les arêtes en tant que références avec uniquement leur et. `id` `label`
## Exécution de script
Toutes les requêtes doivent commencer par `g` qui est l'objet de traversée.
Dans les soumissions de requête de type Chaîne, plusieurs traversées peuvent être émises, séparées par un point-virgule (`;`) ou un caractère de saut de ligne (`\n`). Pour être exécutée, chaque instruction autre que la dernière doit se terminer par une étape `.iterate()`. Seules les données de la traversée finale sont renvoyées. Notez que cela ne s'applique pas aux soumissions de ByteCode requêtes GLV.
## Séances
Les sessions dans Neptune sont limitées à seulement 10 minutes. Voir [Sessions basées sur des scripts Gremlin](access-graph-gremlin-sessions.md) et la [référence de TinkerPop session](https://tinkerpop.apache.org/docs/current/reference/#console-sessions) pour plus d'informations.
## Transactions
Neptune ouvre une nouvelle transaction au début de chaque traversée Gremlin et ferme la transaction lors de la réussite complète de la traversée. La transaction est annulée lorsqu'il y a une erreur.
Plusieurs instructions séparées par un point-virgule (`;`) ou un caractère de nouvelle ligne (`\n`) sont incluses dans une seule transaction. Chaque instruction autre que la dernière doit se terminer par une étape `next()` à exécuter. Seules les données de la traversée finale sont renvoyées.
La logique de transaction manuelle utilisant `tx.commit()` et `tx.rollback()` n'est pas prise en charge.
**Important**
Ceci s'applique ***uniquement*** aux méthodes dans lesquelles vous envoyez la requête Gremlin en tant que ***chaîne de texte*** (voir [Transactions Gremlin](access-graph-gremlin-transactions.md)).
## Vertex et arête IDs
Neptune Gremlin Vertex and Edge IDs doivent être de type. `String` Ces chaînes d'ID prennent en charge les caractères Unicode et ne peuvent pas dépasser 55 Mo.
Les informations fournies par l'utilisateur IDs sont prises en charge, mais elles sont facultatives dans le cadre d'une utilisation normale. Si vous ne fournissez pas d'ID lorsque vous ajoutez un sommet ou une arête, Neptune génère un UUID et le convertit en chaîne, sous une forme similaire à celle-ci : `"48af8178-50ce-971a-fc41-8c9a954cea62"`. Ils UUIDs ne sont pas conformes à la norme RFC, donc si vous avez besoin d'un standard, UUIDs vous devez les générer en externe et les fournir lorsque vous ajoutez des sommets ou des arêtes.
**Note**
La `Load` commande Neptune nécessite que vous fournissiez IDs, en utilisant le champ **\$1id** au format Neptune CSV.
## Fourni par l'utilisateur IDs
Les informations fournies par l'utilisateur IDs sont autorisées dans Neptune G705 sous réserve des stipulations suivantes.
+ IDs Les fournitures sont facultatives.
+ Seuls les vertex et les edges sont pris en charge.
+ Seul le type `String` est pris en charge.
Pour créer un nouveau vertex avec un ID personnalisé, utilisez l'étape `property` avec le mot-clé `id` : `g.addV().property(id, 'customid')`.
**Note**
Ne placez pas de guillemets autour du mot-clé `id`. Il fait référence à `T.id`.
Tous les sommets IDs doivent être uniques et toutes les arêtes IDs doivent être uniques. Cependant, Neptune permet d'avoir le même ID pour un sommet et une arête.
Si vous essayez de créer un nouveau vertex à l'aide de `g.addV()` et qu'il existe déjà un vertex ayant cet ID, l'opération échoue. L'exception à cette règle, c'est que si vous précisez une nouvelle étiquette pour le vertex, l'opération réussit, mais elle ajoute la nouvelle étiquette et toute propriété supplémentaire précisée au sommet existant. Rien n'est remplacé. Un nouveau vertex n'est pas créé. L'ID de sommet ne change pas et reste unique.
Par exemple, les commandes suivantes de la console Gremlin aboutissent :
```
gremlin> g.addV('label1').property(id, 'customid')
gremlin> g.addV('label2').property(id, 'customid')
gremlin> g.V('customid').label()
==>label1::label2
```
## Propriété Vertex IDs
IDs Les propriétés du sommet sont générées automatiquement et peuvent apparaître sous forme de nombres positifs ou négatifs lorsqu'elles sont demandées.
## Cardinalité des propriétés de sommet
Neptune prend en charge la cardinalité définie et la cardinalité unique. Si elle n'est pas spécifiée, la cardinalité définie est sélectionnée. Cela signifie que si vous définissez une valeur de propriété, une nouvelle valeur est ajoutée à la propriété, mais uniquement si elle n'apparaît pas déjà dans l'ensemble de valeurs. Il s'agit de la valeur d'énumération Gremlin [Set](https://tinkerpop.apache.org/javadocs/3.7.2/core/org/apache/tinkerpop/gremlin/structure/VertexProperty.Cardinality.html).
`List` n’est pas pris en charge. Pour plus d'informations sur la cardinalité des propriétés, consultez la rubrique [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...-) dans le Gremlin. JavaDoc
## Mise à jour d'une propriété de sommet
Pour mettre à jour une valeur de propriété sans ajouter une valeur à l'ensemble des valeurs, spécifiez la cardinalité `single` lors de l'étape `property`.
```
g.V('exampleid01').property(single, 'age', 25)
```
Cela supprime toutes les valeurs existantes de la propriété.
## Étiquettes
Neptune prend en charge plusieurs étiquettes pour un sommet. Lorsque vous créez une étiquette, vous pouvez spécifier plusieurs étiquettes en les séparant par `::`. Par exemple, `g.addV("Label1::Label2::Label3")` ajoute un vertex, avec trois étiquettes différentes. L'étape `hasLabel` associe ce sommet à l'une de ces trois étiquettes : `hasLabel("Label1")` `hasLabel("Label2")` et `hasLabel("Label3")`.
**Important**
Le délimiteur `::` est réservé à cet usage uniquement. Vous ne pouvez pas spécifier plusieurs étiquettes dans l'étape `hasLabel`. Par exemple, `hasLabel("Label1::Label2")` ne correspond à rien.
## Caractères d'échappement
Neptune résout tous les caractères d'échappement comme décrit dans la section [Escaping Special Characters]( http://groovy-lang.org/syntax.html#_escaping_special_characters) (Échappement des caractères spéciaux) de la documentation du langage Apache Groovy.
## Limites Groovy
Neptune ne prend pas en charge les commandes Groovy qui ne commencent pas par `g`. Cela inclut les calculs (par exemple, `1+1`), les appels système (par exemple, `System.nanoTime()`) et les définitions de variable (par exemple, `1+1`).
**Important**
Neptune ne prend pas en charge les noms de classe complets. Par exemple, vous devez utiliser `single` et non `org.apache.tinkerpop.gremlin.structure.VertexProperty.Cardinality.single` dans votre demande Groovy.
## Sérialisation
Neptune prend en charge les sérialisations suivantes en fonction du type MIME demandé.
Neptune expose tous les sérialiseurs qui le TinkerPop font, avec le support des différentes versions et configurations de GraphSon et. GraphBinary Bien que de nombreuses options soient présentes, les conseils à suivre sont simples :
+ Si vous utilisez des TinkerPop pilotes Apache, préférez le pilote par défaut sans en spécifier un explicitement. À moins que vous n'ayez une raison très précise de le faire, vous n'avez probablement pas besoin de spécifier le sérialiseur lors de l'initialisation de votre pilote. En général, la valeur par défaut utilisée par les pilotes est`application/vnd.graphbinary-v1.0`.
+ Si vous vous connectez à Neptune via HTTP, privilégiez l'utilisation de `application/vnd.gremlin-v3.0+json;types=false` car les types intégrés dans la version alternative de GraphSon 3 compliquent l'utilisation.
+ Le n'`application/vnd.graphbinary-v1.0-stringd`est généralement utile que lorsqu'il est utilisé conjointement avec la [console Gremlin](https://docs.aws.amazon.com//neptune/latest/userguide/access-graph-gremlin-console.html), car il convertit tous les résultats en une représentation sous forme de chaîne pour un affichage simple.
+ Les autres formats restent présents pour des raisons héritées du passé et ne doivent généralement pas être utilisés avec des pilotes sans raison claire.
| | | |
| --- |--- |--- |
| Type MIME | Sérialisation | Configuration |
| `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(fonctionne uniquement avec 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 | |
**Note**
Le tableau du sérialiseur présenté ici fait référence à la dénomination à partir de la version 3.7.0. TinkerPop Si vous souhaitez en savoir plus sur cette modification, consultez la [documentation de TinkerPop mise à niveau](https://tinkerpop.apache.org/docs/current/upgrade/#_serializer_renaming). Le support de sérialisation de Gryo est devenu obsolète dans la version 3.4.3 et a été officiellement supprimée dans la version 3.6.0. Si vous utilisez explicitement Gryo ou si vous utilisez une version du pilote qui l'utilise par défaut, vous devez passer à votre pilote GraphBinary ou le mettre à niveau.
## Étapes Lambda
Neptune ne prend pas en charge les étapes Lambda.
## Méthodes Gremlin non prises en charge
Neptune ne prend pas en charge les méthodes Gremlin suivantes :
+ `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)`
Par exemple, la traversée suivante n'est pas autorisée : `g.V().addE('something').from(__.V().next()).to(__.V().next())`.
**Important**
Ceci s'applique ***uniquement*** aux méthodes dans lesquelles vous envoyez la requête Gremlin en tant que ***chaîne de texte***.
## Étapes Gremlin non prises en charge
Neptune ne prend pas en charge les étapes Gremlin suivantes :
+ L'[étape Gremlin io ()](http://tinkerpop.apache.org/docs/3.7.2/reference/#io-step) n'est que partiellement prise en charge dans Neptune. Elle peut être utilisée dans un contexte de lecture, par exemple `g.io((url)).read()`, mais pas pour écrire.
## Fonctionnalités du graphe Gremlin dans Neptune
L'implémentation Neptune de Gremlin n'expose pas l'objet `graph`. Les tableaux suivants répertorient les fonctionnalités Gremlin et indiquent si Neptune les prend en charge ou non.
### Prise en charge Neptune des fonctionnalités `graph`
Les fonctionnalités de graphe Neptune sont les mêmes que celles qui seraient renvoyées par la commande `graph.features()`.
|
|
| Fonctionnalité de graphe | Activé ? |
| --- |--- |
| Transactions | vrai |
| ThreadedTransactions | false |
| Computer | false |
| Persistence | true |
| ConcurrentAccess | true |
### Prise en charge Neptune des fonctionnalités de variable
|
|
| Fonctionnalité de variable | Activé ? |
| --- |--- |
| 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 |
### Prise en charge Neptune des fonctionnalités de sommet
|
|
| Fonctionnalité de sommet | Activé ? |
| --- |--- |
| MetaProperties | false |
| DuplicateMultiProperties | false |
| AddVertices | true |
| RemoveVertices | true |
| MultiProperties | true |
| UserSuppliedIds | true |
| AddProperty | true |
| RemoveProperty | vrai |
| NumericIds | false |
| StringIds | vrai |
| UuidIds | false |
| CustomIds | false |
| AnyIds | false |
### Prise en charge Neptune des fonctionnalités de propriété de sommet
|
|
| Fonctionnalité de propriété de sommet | Activé ? |
| --- |--- |
| UserSuppliedIds | false |
| AddProperty | true |
| RemoveProperty | true |
| NumericIds | true |
| StringIds | vrai |
| UuidIds | false |
| CustomIds | false |
| AnyIds | false |
| Properties | vrai |
| SerializableValues | false |
| UniformListValues | false |
| BooleanArrayValues | false |
| DoubleArrayValues | false |
| IntegerArrayValues | false |
| StringArrayValues | false |
| BooleanValues | true |
| ByteValues | true |
| DoubleValues | true |
| FloatValues | true |
| IntegerValues | true |
| LongValues | vrai |
| MapValues | false |
| MixedListValues | false |
| StringValues | vrai |
| ByteArrayValues | false |
| FloatArrayValues | false |
| LongArrayValues | false |
### Prise en charge Neptune des fonctionnalités d'arête
|
|
| Fonctionnalité d'arête | Activé ? |
| --- |--- |
| AddEdges | true |
| RemoveEdges | true |
| UserSuppliedIds | true |
| AddProperty | true |
| RemoveProperty | vrai |
| NumericIds | false |
| StringIds | vrai |
| UuidIds | false |
| CustomIds | false |
| AnyIds | false |
### Prise en charge Neptune des fonctionnalités de propriété d'arête
|
|
| Fonctionnalité de propriété d'arête | Activé ? |
| --- |--- |
| Properties | vrai |
| SerializableValues | false |
| UniformListValues | false |
| BooleanArrayValues | false |
| DoubleArrayValues | false |
| IntegerArrayValues | false |
| StringArrayValues | false |
| BooleanValues | true |
| ByteValues | true |
| DoubleValues | true |
| FloatValues | true |
| IntegerValues | true |
| LongValues | vrai |
| MapValues | false |
| MixedListValues | false |
| StringValues | vrai |
| ByteArrayValues | false |
| FloatArrayValues | false |
| LongArrayValues | false |
# Conformité d'Amazon Neptune avec les normes SPARQL
Après avoir répertorié les normes SPARQL applicables, les sections suivantes fournissent des détails spécifiques sur la manière dont l'implémentation SPARQL de Neptune étend ces normes ou diverge de celles-ci.
**Topics**
+ [Normes applicables pour SPARQL](#feature-sparql-applicable-standards)
+ [Préfixes d'espace de noms par défaut dans Neptune SPARQL](#sparql-default-prefixes)
+ [Graphe par défaut SPARQL et graphes nommés](#sparql-default-graph)
+ [Fonctions du XPath constructeur SPARQL prises en charge par Neptune](#access-graph-sparql-xpath-constructors)
+ [IRI de base par défaut pour les requêtes et les mises à jour](#opencypher-compliance-default-iri)
+ [Valeurs xsd:dateTime dans Neptune](#access-graph-sparql-xsd-date-time)
+ [Traitement des valeurs spéciales à virgule flottante par Neptune](#feature-overview-special-values-comparisons)
+ [Limite Neptune des valeurs de longueur arbitraire](#feature-overview-arbitrary-length-values)
+ [Neptune étend la comparaison Equals dans SPARQL](#feature-overview-sparql-not-equal)
+ [Gestion des Out-of-Range littéraux dans Neptune SPARQL](#feature-overview-sparql-out-of-range)
Amazon Neptune est conforme avec les normes suivantes lors de l'implémentation du langage de requête de graphe SPARQL.
## Normes applicables pour SPARQL
+ SPARQL est défini par la recommandation du W3C [SPARQL 1.1 Query Language](https://www.w3.org/TR/sparql11-query/) du 21 mars 2013.
+ Le protocole de mise à jour SPARQL et le langage de requête sont définis par la spécification W3C [SPARQL 1.1 Update](https://www.w3.org/TR/sparql11-update/).
+ Pour les formats numériques, SPARQL suit la spécification [XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes](https://www.w3.org/TR/xmlschema11-2/) du W3C qui est compatible avec la spécification IEEE 754 ([IEEE 754-2019 - IEEE Standard for Floating-Point Arithmetic](https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html) ; voir aussi la [page Wikipedia sur IEEE 754](https://en.wikipedia.org/wiki/IEEE_754)). Toutefois, les fonctionnalités introduites après la version `IEEE 754-1985` ne sont pas incluses dans la spécification.
## Préfixes d'espace de noms par défaut dans Neptune SPARQL
Neptune définit les préfixes suivants par défaut à utiliser dans les requêtes SPARQL. Pour plus d'informations, consultez [Noms préfixés](https://www.w3.org/TR/sparql11-query/#prefNames) dans la spécification 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#`
## Graphe par défaut SPARQL et graphes nommés
Amazon Neptune associe chaque triplet à un graphe nommé. Le graphe par défaut est défini comme l'union de tous les graphes nommés.
**Graphe par défaut pour les requêtes**
Si vous envoyez une requête SPARQL sans spécifier explicitement un graphe via le mot-clé `GRAPH` ou des constructions telles que `FROM NAMED`, Neptune prend toujours en compte tous les triplets dans votre instance de base de données. Par exemple, la requête suivante renvoie tous les triplets à partir d'un point de terminaison Neptune SPARQL :
`SELECT * WHERE { ?s ?p ?o }`
Les triplets qui apparaissent dans plusieurs graphes ne sont renvoyés qu'une seule fois.
Pour plus d'informations sur la spécification du graphe par défaut, consultez la section [RDF Dataset](https://www.w3.org/TR/sparql11-query/#rdfDataset) dans la spécification de langage de requête SPARQL 1.1.
**Spécification du graphe nommé pour le chargement, les insertions ou les mises à jour**
Si vous ne spécifiez pas un graphe nommé lors du chargement, de l'insertion ou de la mise à jour de triplets, Neptune utilise le graphe nommé de secours défini par l'URI `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`.
Lorsque vous envoyez une demande `Load` Neptune à l'aide d'un format basé sur les triplets, vous pouvez spécifier le graphe nommé à utiliser pour tous les triplets à l'aide du paramètre `parserConfiguration: namedGraphUri`. Pour plus d'informations sur la syntaxe de la commande `Load`, consultez [Commande de chargeur Neptune](load-api-reference-load.md).
**Important**
Si vous n'utilisez pas ce paramètre, et que vous ne spécifiez pas un graphe nommé, l'URI de secours est utilisé : `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`.
Ce graphe nommé de secours est également utilisé si vous chargez des triplets via `SPARQL UPDATE` sans fournir explicitement une cible de graphe nommé.
Vous pouvez utiliser le format basé sur les quadrilatères NQuads afin de spécifier un graphe nommé pour chaque triplet de la base de données.
**Note**
L'utilisation de NQuads vous permet de laisser vide le graphe nommé. Dans ce cas, `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph` est utilisé.
Vous pouvez remplacer le graphe nommé par défaut pour NQuads à l'aide de l'option de configuration de l'analyseur `namedGraphUri`.
## Fonctions du XPath constructeur SPARQL prises en charge par Neptune
La norme SPARQL permet aux moteurs SPARQL de prendre en charge un ensemble extensible de fonctions de XPath constructeur. Neptune prend actuellement en charge les fonctions de constructeur suivantes, dont le préfixe `xsd` est défini comme `http://www.w3.org/2001/XMLSchema#` :
+ `xsd:boolean`
+ `xsd:integer`
+ `xsd:double`
+ `xsd:float`
+ `xsd:decimal`
+ `xsd:long`
+ `xsd:unsignedLong`
## IRI de base par défaut pour les requêtes et les mises à jour
Comme un cluster Neptune possède plusieurs points de terminaison différents, l'utilisation de l'URL de demande d'une requête ou d'une mise à jour comme IRI de base peut entraîner des résultats inattendus lors de la résolution relative. IRIs
Depuis la [version 1.2.1.0 du moteur](engine-releases-1.2.1.0.md), Neptune utilise `http://aws.amazon.com/neptune/default/` comme IRI de base si aucun IRI de base explicite ne fait partie de la demande.
Dans la demande suivante, l'IRI de base fait partie de la demande :
```
BASE
INSERT DATA { "n1" }
BASE
SELECT * { ?p ?o }
```
Le résultat serait le suivant :
```
?p ?o
http://example.org/default/id n1
```
En revanche, dans cette demande, aucun IRI de base n'est inclus :
```
INSERT DATA { "n1" }
SELECT * { ?p ?o }
```
Dans ce cas, le résultat serait :
```
?p ?o
http://aws.amazon.com/neptune/default/id n1
```
## Valeurs xsd:dateTime dans Neptune
Pour des raisons de performance, Neptune stocke toujours les date/time valeurs en temps universel coordonné (UTC). Cela rend les comparaisons directes très efficaces.
Cela signifie également que si vous entrez une valeur `dateTime` spécifiant un fuseau horaire particulier, Neptune convertit cette valeur en UTC et rejette ces informations de fuseau horaire. Ensuite, lorsque vous récupérez la valeur `dateTime` ultérieurement, elle est exprimée en UTC, et non en heure du fuseau horaire d'origine, et vous ne pouvez plus savoir quel était ce fuseau horaire d'origine.
## Traitement des valeurs spéciales à virgule flottante par Neptune
Neptune traite les valeurs spéciales à virgule flottante dans SPARQL comme suit :
### Gestion des valeurs NaN SPARQL dans Neptune
Dans Neptune, SPARQL peut accepter une valeur `NaN` dans une requête. Aucune distinction n'est faite entre les valeurs `NaN` de signalisation et silencieuses. Neptune considère toutes les valeurs `NaN` comme étant silencieuses.
D'un point de vue sémantique, aucune comparaison d'une valeur `NaN` n'est possible, car aucune valeur n'est supérieure, inférieure ou égale à une valeur `NaN`. Cela signifie qu'une valeur `NaN` d'un côté d'une comparaison ne correspond jamais à *quoi que ce soit* de l'autre côté.
Cependant, la [spécification XSD](https://www.w3.org/TR/xmlschema-2/#double) traite deux valeurs `NaN` `xsd:double` ou `xsd:float` comme égales. Neptune respecte ce principe pour le filtre `IN`, pour l'opérateur égal dans les expressions de filtre, et pour la sémantique de correspondance exacte (ayant un élément `NaN` dans la position de l'objet d'un modèle triple).
### Traitement des valeurs infinies SPARQL dans Neptune
Dans Neptune, SPARQL peut accepter une valeur `INF` ou `-INF` dans une requête. Une valeur `INF` est comparée comme étant supérieure à toute autre valeur numérique, et une valeur `-INF` est comparée comme étant inférieure à toute autre valeur numérique.
Deux valeurs INF avec des signes correspondants sont égales l'une à l'autre quel que soit leur type (par exemple, un nombre à virgule flottante `-INF` est égal à un double `-INF`).
Bien sûr, aucune comparaison avec une valeur `NaN` n'est possible, car aucune valeur n'est supérieure, inférieure ou égale à une valeur `NaN`.
### Traitement du zéro négatif SPARQL dans Neptune
Neptune normalise une valeur de zéro négatif en un zéro non signé. Des valeurs nulles négatives peuvent être utilisées dans une requête, mais elles ne sont pas enregistrées en tant que telles dans la base de données et elles sont comparées comme étant égales à des zéros non signés.
## Limite Neptune des valeurs de longueur arbitraire
Neptune limite à 64 bits la taille de stockage des valeurs entières, à virgule flottante et décimales XSD dans SPARQL. L'utilisation de valeurs plus grandes génère une erreur `InvalidNumericDataException`.
## Neptune étend la comparaison Equals dans SPARQL
La norme SPARQL définit une logique ternaire pour les expressions de valeur, dans lesquelles une expression de valeur peut être évaluée à `true`, `false` ou `error`. La sémantique par défaut pour l'égalité des termes telle que définie dans la [spécification SPARQL 1.1](https://www.w3.org/TR/sparql11-query/#func-RDFterm-equal), qui s'applique aux comparaisons `=` et `!=` dans des conditions `FILTER` génère une `error` lors de la comparaison de types de données qui ne sont pas comparables explicitement dans la [table des opérateurs](https://www.w3.org/TR/sparql11-query/#OperatorMapping) dans la spécification.
Ce comportement peut entraîner des résultats non intuitifs, comme dans l'exemple suivant.
Données :
```
"127.0.0.1"^^
```
Requête 1 :
```
SELECT * WHERE {
?o .
FILTER(?o = "127.0.0.2"^^)
}
```
Requête 2 :
```
SELECT * WHERE {
?o .
FILTER(?o != "127.0.0.2"^^)
}
```
Avec la sémantique SPARQL par défaut utilisée par Neptune avant la version 1.0.2.1, les deux requêtes renvoyaient le résultat vide. En effet, `?o = "127.0.0.2"^^`, lorsqu'il est évalué pour `?o := "127.0.0.1"^^`, génère le résultat `error` plutôt que `false`, car aucune règle de comparaison explicite n'est spécifiée pour le type de données personnalisé ``. Par conséquent, la version négative dans la deuxième requête produit également une `error`. Dans les deux requêtes, `error` provoque le filtrage de la solution candidate.
À partir de la version 1.0.2.1, Neptune a étendu l'opérateur d'inégalité SPARQL conformément à la spécification. Consultez la [section SPARQL 1.1 sur l'extensibilité de l'opérateur](https://www.w3.org/TR/sparql11-query/#operatorExtensibility), qui permet aux moteurs de définir des règles supplémentaires sur la façon d'effectuer une comparaison entre des types de données intégrés définis par l'utilisateur et non comparables.
En utilisant cette option, Neptune traite désormais une comparaison de deux types de données qui n'est pas explicitement définie dans la table de mappage des opérateurs comme prenant la valeur `true` si les valeurs littérales et les types de données sont égaux d'un point de vue syntaxique, ou comme prenant la valeur false dans le cas contraire. Un `error` n'est en aucun cas produit.
En utilisant ces nouvelles sémantiques, la deuxième requête renverrait `"127.0.0.1"^^` au lieu d'un résultat vide.
## Gestion des Out-of-Range littéraux dans Neptune SPARQL
La sémantique XSD définit chaque type numérique avec son espace de valeurs, à l'exception de `integer` et `decimal`. Ces définitions limitent chaque type à une plage de valeurs. Par exemple, la plage d'une plage `xsd:byte` est comprise entre -128 et \$1127, inclusivement. Toute valeur en dehors de cette plage est considérée comme non valide.
Si vous essayez d'attribuer une valeur littérale en dehors de l'espace des valeurs d'un type (par exemple, si vous essayez de définir an `xsd:byte` sur une valeur littérale de 999), Neptune accepte la out-of-range valeur telle quelle, sans l'arrondir ni la tronquer. Mais il ne le persiste pas en tant que valeur numérique car le type donné ne peut pas le représenter.
Autrement dit, Neptune accepte `"999"^^xsd:byte` même s'il s'agit d'une valeur qui se trouve en dehors de la plage de valeurs `xsd:byte` définie. Cependant, une fois la valeur conservée dans la base de données, elle ne peut être utilisée que dans la sémantique de correspondance exacte, dans une position d'objet d'un motif triple. Aucun filtre de plage ne peut y être exécuté car out-of-range les littéraux ne sont pas traités comme des valeurs numériques.
La spécification SPARQL 1.1 définit les [opérateurs de plage](https://www.w3.org/TR/sparql11-query/#OperatorMapping) sous la forme `numeric` *-operator-*`numeric`, `string` *-operator-*`string`, `literal`*-operator-*`literal`, etc. Neptune ne peut pas exécuter un opérateur de comparaison de plages tel que `invalid-literal`*-operator-*`numeric-value`.
# Conformité aux spécifications OpenCypher dans Amazon Neptune
La version Amazon Neptune d'openCypher prend généralement en charge les clauses, les opérateurs, les expressions, les fonctions et la syntaxe définis dans la spécification openCypher actuelle, à savoir la [version 9 de Cypher Query Language Reference](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf). Les limites et les différences relatives à la prise en charge d'openCypher par Neptune sont décrites ci-dessous.
Amazon Neptune prend également en charge plusieurs fonctionnalités qui ne sont pas couvertes par la spécification OpenCypher. Pour plus d'informations, consultez [Extensions OpenCypher dans Amazon Neptune](access-graph-opencypher-extensions.md).
**Note**
L'implémentation Neo4j actuelle de Cypher contient des fonctionnalités qui ne se trouvent pas dans la spécification openCypher mentionnée ci-dessus. Si vous migrez le code Cypher actuel vers Neptune, consultez [Compatibilité de Neptune avec Neo4j](migration-compatibility.md) et [Réécriture des requêtes Cypher pour les exécuter dans openCypher sur Neptune](migration-opencypher-rewrites.md) pour plus d'informations.
## Prise en charge des clauses openCypher dans Neptune
Neptune prend en charge les clauses suivantes, sauf indication contraire :
+ `MATCH` : prise en charge, mais pas *`shortestPath()`* et *`allShortestPaths()`*
+ `OPTIONAL MATCH`
+ *`MANDATORY MATCH`* : **n'est actuellement pas** pris en charge dans Neptune. Neptune prend toutefois en charge les [valeurs d'ID personnalisées](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids) dans les requêtes `MATCH`.
+ `RETURN` : pris en charge, sauf lorsqu'il est utilisé avec des valeurs non statiques pour `SKIP` ou `LIMIT`. Par exemple, voici ce qui ne fonctionne pas pour l'instant :
```
MATCH (n)
RETURN n LIMIT toInteger(rand()) // Does NOT work!
```
+ `WITH` : pris en charge, sauf lorsqu'il est utilisé avec des valeurs non statiques pour `SKIP` ou `LIMIT`. Par exemple, voici ce qui ne fonctionne pas pour l'instant :
```
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 vous permet de créer des [valeurs d'ID personnalisées](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids) dans les requêtes `CREATE`.
+ `DELETE`
+ `SET`
+ `REMOVE`
+ `MERGE` : Neptune prend en charge les [valeurs d'ID personnalisées](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids) dans les requêtes `MERGE`.
+ *`CALL[YIELD...]`* : **n'est actuellement pas** pris en charge dans Neptune.
+ `UNION, UNION ALL` : les requêtes en lecture seule sont prises en charge, mais les requêtes de mutation **ne le sont pas** actuellement.
+ `USING`— `USING` est pris en charge depuis la version [1.3.2.0](https://docs.aws.amazon.com//neptune/latest/userguide/engine-releases-1.3.2.0.html) du moteur. Voir [Conseils relatifs aux requêtes](https://docs.aws.amazon.com//neptune/latest/userguide/opencypher-query-hints.html) pour plus d'informations.
## Prise en charge des opérateurs openCypher dans Neptune
Neptune prend en charge les opérateurs suivants, sauf indication contraire :
**Opérateurs généraux**
+ `DISTINCT`
+ L'opérateur `.` permettant d'accéder aux propriétés d'un mappage de littéraux imbriqué.
**Operateurs mathématiques**
+ Opérateur d'addition `+`.
+ L'opérateur de soustraction `-`.
+ Opérateur de multiplication `*`.
+ L'opérateur de division `/`.
+ L'opérateur de division modulo `%`.
+ L'opérateur d'`^`exponentiation. *is NOT supported*
**Opérateurs de comparaison**
+ Opérateur d'addition `=`.
+ L'opérateur d'égalité `<>`.
+ L'opérateur `<` (inférieur à) est pris en charge sauf lorsque l'un des arguments est un chemin, une liste ou un mappage.
+ L'opérateur `>` (supérieur à) est pris en charge sauf lorsque l'un des arguments est un chemin, une liste ou un mappage.
+ L'opérateur `<=` less-than-or-equal -to est pris en charge sauf lorsque l'un des arguments est un chemin, une liste ou une carte.
+ L'opérateur `>=` greater-than-or-equal -to est pris en charge sauf lorsque l'un des arguments est un chemin, une liste ou une carte.
+ `IS NULL`
+ `IS NOT NULL`
+ `STARTS WITH` est pris en charge si les données recherchées correspondant à une chaîne.
+ `ENDS WITH` est pris en charge si les données recherchées correspondant à une chaîne.
+ `CONTAINS` est pris en charge si les données recherchées correspondant à une chaîne.
**Opérateurs booléens**
+ `AND`
+ `OR`
+ `XOR`
+ `NOT`
**Opérateurs de chaîne**
+ Opérateur de concaténation `+`.
**Opérateurs de liste**
+ Opérateur de concaténation `+`.
+ `IN` (vérifie la présence d'un élément dans la liste)
## Prise en charge des expressions openCypher dans Neptune
Neptune prend en charge les expressions suivantes, sauf indication contraire :
+ `CASE`
+ L'expression `[]` **n'est actuellement pas** prise en charge dans Neptune pour accéder aux clés de propriété calculées dynamiquement au sein d'un nœud, d'une relation ou d'un mappage. Par exemple, les éléments suivants ne fonctionnent pas :
```
MATCH (n)
WITH [5, n, {key: 'value'}] AS list
RETURN list[1].name
```
## Prise en charge des fonctions openCypher dans Neptune
Neptune prend en charge les fonctions suivantes, sauf indication contraire :
**Fonctions de prédicat**
+ `exists()`
**Fonctions scalaires**
+ `coalesce()`
+ `endNode()`
+ `epochmillis()`
+ `head()`
+ `id()`
+ `last()`
+ `length()`
+ `randomUUID()`
+ `properties()`
+ `removeKeyFromMap`
+ `size()` : cette méthode surchargée ne fonctionne actuellement que pour les expressions de modèles, les listes et les chaînes.
+ `startNode()`
+ `timestamp()`
+ `toBoolean()`
+ `toFloat()`
+ `toInteger()`
+ `type()`
**Fonctions d'agrégation**
+ `avg()`
+ `collect()`
+ `count()`
+ `max()`
+ `min()`
+ `percentileDisc()`
+ `stDev()`
+ `percentileCont()`
+ `stDevP()`
+ `sum()`
**Répertorier des fonctions**
+ [`join()`](access-graph-opencypher-extensions.md#opencypher-compliance-join-function) (concatène les chaînes d'une liste en une seule chaîne)
+ `keys()`
+ `labels()`
+ `nodes()`
+ `range()`
+ `relationships()`
+ `reverse()`
+ `tail()`
**Fonctions mathématiques (numériques)**
+ `abs()`
+ `ceil()`
+ `floor()`
+ `rand()`
+ `round()`
+ `sign()`
**Fonctions mathématiques (logarithmiques)**
+ `e()`
+ `exp()`
+ `log()`
+ `log10()`
+ `sqrt()`
**Fonctions mathématiques (trigonométriques)**
+ `acos()`
+ `asin()`
+ `atan()`
+ `atan2()`
+ `cos()`
+ `cot()`
+ `degrees()`
+ `pi()`
+ `radians()`
+ `sin()`
+ `tan()`
**Fonctions de chaîne**
+ [`join()`](access-graph-opencypher-extensions.md#opencypher-compliance-join-function) (concatène les chaînes d'une liste en une seule chaîne)
+ `left()`
+ `lTrim()`
+ `replace()`
+ `reverse()`
+ `right()`
+ `rTrim()`
+ `split()`
+ `substring()`
+ `toLower()`
+ `toString()`
+ `toUpper()`
+ `trim()`
**Fonctions définies par l'utilisateur**
*User-defined functions***ne sont actuellement pas** pris en charge dans Neptune.
## Détails d'implémentation d'openCypher spécifiques à Neptune
Les sections suivantes décrivent en quoi l'implémentation Neptune d'openCypher peut différer ou aller au-delà de la [spécification openCypher](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf).
### Évaluations des chemins de longueur variable (VLP) dans Neptune
Les évaluations de chemins de longueur variable (`VLP`) découvrent les chemins entre les nœuds du graphe. La longueur du chemin peut être illimitée dans une requête. Pour éviter les cycles, la [spécification openCypher](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf) indique que chaque arête doit être traversée au maximum une fois par solution.
En effet VLPs, l'implémentation de Neptune s'écarte de la spécification OpenCypher en ce sens qu'elle ne prend en charge que les valeurs constantes pour les filtres d'égalité des propriétés. Prenons la requête suivante :
```
MATCH (x)-[:route*1..2 {dist:33, code:x.name}]->(y) return x,y
```
La valeur du filtre d'égalité des propriétés `x.name` n'étant pas une constante, cette requête génère une exception `UnsupportedOperationException` avec le message suivant : `Property predicate over variable-length relationships with non-constant expression is not supported in this release.`
### Support temporel dans l'implémentation de Neptune OpenCypher (base de données Neptune 1.3.1.0 et versions antérieures)
Neptune fournit actuellement une prise en charge limitée de la fonction temporelle dans openCypher. Il prend en charge le type de données `DateTime` pour les types temporels.
La fonction `datetime()` peut être utilisée pour obtenir la date et l'heure UTC actuelles comme suit :
```
RETURN datetime() as res
```
Les valeurs de date et d'heure peuvent être analysées à partir de chaînes dans un format `"`*date*`T`*heure*`"` où *date* et *heure* sont toutes deux exprimées sous l'une des formes prises en charge ci-dessous :
**Formats de date pris en charge**
+ `yyyy-MM-dd`
+ `yyyyMMdd`
+ `yyyy-MM`
+ `yyyy-DDD`
+ `yyyyDDD`
+ `yyyy`
**Formats pris en charge**
+ `HH:mm:ssZ`
+ `HHmmssZ`
+ `HH:mm:ssZ`
+ `HH:mmZ`
+ `HHmmZ`
+ `HHZ`
+ `HHmmss`
+ `HH:mm:ss`
+ `HH:mm`
+ `HHmm`
+ `HH`
Par exemple :
```
RETURN datetime('2022-01-01T00:01') // or another example:
RETURN datetime('2022T0001')
```
Notez que toutes les date/time valeurs de Neptune OpenCypher sont stockées et récupérées sous forme de valeurs UTC.
Neptune openCypher utilise une horloge `statement`, ce qui signifie que le même instant dans le temps est utilisé pendant toute la durée d'une requête. Une requête différente au sein de la même transaction peut utiliser un instant différent.
Neptune ne prend pas en charge l'utilisation d'une fonction dans un appel à `datetime()`. Voici, par exemple, ce qui ne fonctionne pas :
```
CREATE (:n {date:datetime(tostring(2021))}) // ---> NOT ALLOWED!
```
Neptune prend en charge la fonction `epochmillis()` qui convertit une valeur `datetime` en `epochmillis`. Par exemple :
```
MATCH (n) RETURN epochMillis(n.someDateTime)
1698972364782
```
Neptune ne prend actuellement pas en charge les autres fonctions et opérations au niveau des objets `DateTime`, telles que l'addition et la soustraction.
### Support temporel dans l'implémentation de Neptune OpenCypher (Neptune Analytics et Neptune Database 1.3.2.0 et versions ultérieures)
La fonctionnalité date/heure suivante OpenCypher s'applique à Neptune Analytics. Vous pouvez également utiliser le paramètre labmode `DatetimeMillisecond=enabled` pour activer la fonctionnalité datetime suivante sur les versions 1.3.2.0 et supérieures du moteur Neptune. Pour plus de détails sur l'utilisation de cette fonctionnalité en mode laboratoire, consultez[Support date/heure étendu](features-lab-mode.md#labmode-extended-datetime-support).
+ Support en millisecondes. Le littéral Datetime sera toujours renvoyé en millisecondes, même si le nombre de millisecondes est égal à 0. (Le comportement précédent consistait à tronquer des millisecondes.)
```
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 pour appeler la fonction datetime () sur des propriétés stockées ou des résultats intermédiaires. Par exemple, les requêtes suivantes n'étaient pas possibles avant cette fonctionnalité.
Datetime () sur les propriétés :
```
// 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 () sur les résultats intermédiaires :
```
// Parse datetime from parameter
UNWIND $list as myDate
RETURN datetime(myDate) as d
```
+ Il est désormais également possible de sauvegarder les propriétés date/heure créées dans les cas mentionnés ci-dessus.
Sauvegarde de la date et de l'heure de la propriété string d'une propriété vers une autre :
```
// 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)
```
Créez des nœuds par lots à partir d'un paramètre doté d'une propriété 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 d'un plus grand sous-ensemble de formats de ISO8601 date/heure. Reportez-vous à ci-dessous.
Formats pris en charge
Le format d'une valeur date/heure est [Date] T [Heure] [Fuseau horaire], où T est le séparateur. Si aucun fuseau horaire explicite n'est fourni, UTC (Z) est supposé être le fuseau horaire par défaut.
Fuseau horaire
Les formats de fuseau horaire pris en charge sont les suivants :
+ \$1/-HH : mm
+ \$1/-HHmm
+ \$1/-HH
La présence d'un fuseau horaire dans une chaîne de date/heure est facultative. Si le décalage horaire est de 0, Z peut être utilisé à la place du suffixe de fuseau horaire ci-dessus pour indiquer l'heure UTC. La plage prise en charge d'un fuseau horaire est comprise entre -14h00 et \$114h00.
Date
Si aucun fuseau horaire n'est présent ou si le fuseau horaire est UTC (Z), les formats de date pris en charge sont les suivants :
**Note**
DDD fait référence à une date ordinale, qui représente un jour de l'année compris entre 001 et 365 (366 les années bissextiles). Par exemple, 2024-002 représente le 2 janvier 2024.
+ `yyyy-MM-dd`
+ `yyyyMMdd`
+ `yyyy-MM`
+ `yyyyMM`
+ `yyyy-DDD`
+ `yyyyDDD`
+ `yyyy`
Si un fuseau horaire autre que Z est choisi, les formats de date pris en charge sont limités aux suivants :
+ `yyyy-MM-dd`
+ `yyyy-DDD`
+ `yyyyDDD`
La plage de dates prise en charge est comprise entre 1400-01-01 et 9999-12-31.
Heure
Si aucun fuseau horaire n'est présent ou si le fuseau horaire est UTC (Z), les formats horaires pris en charge sont les suivants :
+ `HH:mm:ss.SSS`
+ `HH:mm:ss`
+ `HHmmss.SSS`
+ `HHmmss`
+ `HH:mm`
+ `HHmm`
+ `HH`
Si un fuseau horaire autre que Z est choisi, les formats horaires pris en charge sont limités aux suivants :
+ `HH:mm:ss`
+ `HH:mm:ss.SSS`
### Différences de sémantique du langage Neptune openCypher
Neptune représente le nœud et la relation IDs sous forme de chaînes plutôt que d'entiers. L'ID équivaut à celui fourni par le biais du chargeur de données. S'il existe un espace de noms pour la colonne, il s'agit de l'espace de noms plus l'ID. Par conséquent, la fonction `id` renvoie une chaîne au lieu d'un entier.
Le type de données `INTEGER` est limité à 64 bits. Lors de la conversion de valeurs à virgule flottante ou de valeurs de chaîne plus grandes en entier à l'aide de la fonction `TOINTEGER`, les valeurs négatives sont tronquées en `LLONG_MIN`, et les valeurs positives sont tronquées en `LLONG_MAX`.
Par exemple :
```
RETURN TOINTEGER(2^100)
> 9223372036854775807
RETURN TOINTEGER(-1 * 2^100)
> -9223372036854775808
```
### Propriétés à valeurs multiples
Bien qu'OpenCypher CREATE ne crée pas de propriétés à valeurs multiples, celles-ci peuvent exister dans les données créées à l'aide de Gremlin (base de données Neptune) ou lors du chargement de données (base de données Neptune et Neptune Analytics). Si Neptune openCypher trouve une propriété à valeurs multiples, l'une de ces valeurs est choisie arbitrairement, ce qui crée un résultat non déterministe.
### Gestion des valeurs NaN
La façon dont Neptune gère la comparaison des valeurs des `NaN` propriétés n'est pas définie. Le fait de s'appuyer sur de telles comparaisons peut donner des résultats inattendus ou non déterministes.