Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Notas sobre la conformidad con los estándares de Amazon Neptune
Amazon Neptune cumple los estándares aplicables en la implementación de los lenguajes de consulta de gráficos Gremlin y SPARQL en la mayoría de los casos.
En estas secciones, se describen los estándares, así como las áreas en las que Neptune los amplía o se diferencia de ellos.
**Topics**
+ [Conformidad con los estándares de Gremlin en Amazon Neptune](access-graph-gremlin-differences.md)
+ [Conformidad con los estándares de SPARQL en Amazon Neptune](feature-sparql-compliance.md)
+ [Conformidad con la especificación de openCypher en Amazon Neptune](feature-opencypher-compliance.md)
# Conformidad con los estándares de Gremlin en Amazon Neptune
Las siguientes secciones proporcionan una descripción general de la implementación de Gremlin en Neptune y en qué se diferencia de la implementación de Apache. TinkerPop
Neptune implementa algunos pasos de Gremlin de forma nativa en su motor y usa la implementación de Apache TinkerPop Gremlin para procesar otros (consulte). [Compatibilidad nativa con pasos de Gremlin en Amazon Neptune](gremlin-step-support.md)
**nota**
Para ver algunos ejemplos concretos de estas diferencias de implementación que se muestran en la consola de Gremlin y Amazon Neptune, consulte la sección [Uso de Gremlin para acceder a datos de gráficos en Amazon Neptune](get-started-graph-gremlin.md) del inicio rápido.
**Topics**
+ [Estándares aplicables de Gremlin](#feature-gremlin-applicable-standards)
+ [Variables y parámetros en los scripts](#feature-gremlin-differences-variables)
+ [TinkerPop enumeraciones](#feature-gremlin-differences-tinkerpop)
+ [Código Java](#feature-gremlin-differences-java)
+ [Propiedades de los elementos](#feature-gremlin-differences-properties-on-elements)
+ [Ejecución de scripts](#feature-gremlin-differences-script)
+ [Sesiones](#feature-gremlin-differences-sessions)
+ [Transacciones](#feature-gremlin-differences-transactions)
+ [Vértice y arista IDs](#feature-gremlin-differences-vertex-edge-ids)
+ [Proporcionado por el usuario IDs](#feature-gremlin-differences-user-supplied-ids)
+ [Propiedad del vértice IDs](#feature-gremlin-differences-vertex-property-ids)
+ [Cardinalidad de las propiedades de vértice](#feature-gremlin-differences-vertex-property-cardinality)
+ [Actualización de una propiedad de vértice](#feature-gremlin-differences-vertex-property-update)
+ [Etiquetas](#feature-gremlin-differences-labels)
+ [Caracteres de escape](#feature-gremlin-differences-escapes)
+ [Limitaciones de Groovy](#feature-gremlin-differences-groovy)
+ [Serialización](#feature-gremlin-differences-serialization)
+ [Pasos de Lambda](#feature-gremlin-differences-lambda)
+ [Métodos de Gremlin no admitidos](#feature-gremlin-differences-unsupported-methods)
+ [Pasos de Gremlin no admitidos](#feature-gremlin-differences-unsupported-steps)
+ [Características de gráficos de Gremlin en Neptune](#gremlin-api-reference-features)
## Estándares aplicables de Gremlin
+ El lenguaje Gremlin se define en la [ TinkerPop documentación de Apache y en la TinkerPop implementación de Gremlin en Apache](http://tinkerpop.apache.org/docs/current/reference/), más que en una especificación formal.
+ En el caso de los formatos numéricos, Gremlin sigue el estándar IEEE 754 ([IEEE 754-2019 - Estándar IEEE para aritmética de punto flotante](https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html). Para obtener más información, consulte también la [página de la Wikipedia sobre IEEE 754](https://en.wikipedia.org/wiki/IEEE_754)).
## Variables y parámetros en los scripts
En lo que respecta a las variables previamente enlazadas, el objeto de recorrido `g` está enlazado previamente en Neptune y no se admite el objeto `graph`.
Aunque Neptune no admite variables de Gremlin ni la parametrización en los scripts, a menudo encontrará en Internet ejemplos de scripts del servidor de Gremlin que contienen declaraciones de variables, como:
```
String query = "x = 1; g.V(x)";
List results = client.submit(query).all().get();
```
También hay muchos ejemplos que utilizan la [parametrización](https://tinkerpop.apache.org/docs/current/reference/#parameterized-scripts) (o enlaces) al enviar consultas, como:
```
Map params = new HashMap<>();
params.put("x",1);
String query = "g.V(x)";
List results = client.submit(query).all().get();
```
Los ejemplos de parámetros suelen estar asociados a advertencias sobre penalizaciones en el rendimiento si no se parametriza cuando es posible. Puede encontrar muchos ejemplos de este tipo, y todos parecen bastante convincentes en cuanto TinkerPop a la necesidad de parametrizar.
Sin embargo, tanto la función de declaración de variables como la función de parametrización (junto con las advertencias) solo se aplican al servidor Gremlin cuando se utiliza TinkerPop el. `GremlinGroovyScriptEngine` No se aplican cuando el servidor de Gremlin utiliza la gramática ANTLR `gremlin-language` de Gremlin para analizar las consultas. La gramática de ANTLR no admite ni las declaraciones de variables ni la parametrización, por lo que cuando utilice ANTLR, no tiene que preocuparse por no poder parametrizar. Como la gramática del ANTLR es un componente más reciente TinkerPop, el contenido más antiguo que puedas encontrar en Internet no suele reflejar esta distinción.
Neptune utiliza la gramática de ANTLR en su motor de procesamiento de consultas en lugar del `GremlinGroovyScriptEngine`, por lo que no admite variables, parametrización ni la propiedad `bindings`. Como resultado, los problemas relacionados con la falta de parametrización no se aplican en Neptune. Con Neptune, es perfectamente seguro enviar la consulta tal cual, cuando lo normal sería parametrizarla. Como resultado, el ejemplo anterior se puede simplificar sin ninguna penalización en el rendimiento de la siguiente manera:
```
String query = "g.V(1)";
List results = client.submit(query).all().get();
```
## TinkerPop enumeraciones
Neptune no admite nombres completos de clase para los valores de enumeración. Por ejemplo, debe utilizar `single` y no `org.apache.tinkerpop.gremlin.structure.VertexProperty.Cardinality.single` en la solicitud de Groovy.
El tipo de enumeración viene determinado por el tipo de parámetro.
En la siguiente tabla se muestran los valores de enumeración permitidos y el nombre TinkerPop completo correspondiente.
| Valores permitidos | Clase |
| --- |--- |
| 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. Cardinalidad](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.Barrera](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.Elige](https://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/process/traversal/Pick.html) |
## Código Java
Neptune no admite llamadas a métodos definidos por llamadas arbitrarias de Java o a bibliotecas de Java distintas de las compatibles con Gremlin. APIs Por ejemplo `java.lang.*`, `Date()` y `g.V().tryNext().orElseGet()` no se permiten.
## Propiedades de los elementos
Neptune no admite la `materializeProperties` bandera que se introdujo en la TinkerPop versión 3.7.0 para devolver las propiedades de los elementos. Como resultado, Neptune seguirá devolviendo únicamente vértices o bordes como referencias solo con su `id` y `label`.
## Ejecución de scripts
Todas las consultas debe comenzar por `g`, el objeto de recorrido.
En los envíos de consulta de cadena, se pueden emitir varios recorridos separados por punto y coma (`;`) o por un carácter de nueva línea (`\n`). Para ejecutarse, todas las instrucciones, aparte de la última, deben finalizar con un paso `.iterate()`. Solo se devuelven los datos del recorrido final. Tenga en cuenta que esto no se aplica a los envíos de consultas de GLV ByteCode .
## Sesiones
Las sesiones en Neptune se limitan a una duración de 10 minutos. Consulte [Sesiones basadas en scripts de Gremlin](access-graph-gremlin-sessions.md) la [referencia de la TinkerPop sesión](https://tinkerpop.apache.org/docs/current/reference/#console-sessions) para obtener más información.
## Transacciones
Neptune abre una nueva transacción al principio de cada recorrido de Gremlin y la cierra una vez que este se completa correctamente. La transacción se revierte si se produce un error.
Varias instrucciones separadas por punto y coma (`;`) o por un carácter de nueva línea (`\n`) se incluyen en una sola transacción. Todas las instrucciones, aparte de la última, deben finalizar con un paso `next()` para ejecutarse. Solo se devuelven los datos del recorrido final.
No se admite la lógica de transacción manual que utiliza `tx.commit()` y `tx.rollback()`.
**importante**
Esto ***solo*** se aplica a aquellos casos en los que envíe la consulta de Gremlin como una ***cadena de texto*** (consulte [Transacciones de Gremlin](access-graph-gremlin-transactions.md)).
## Vértice y arista IDs
El vértice y la arista IDs de Neptune Gremlin deben ser del tipo. `String` Estas cadenas de identificación admiten caracteres Unicode y su tamaño no puede superar los 55 MB.
IDs Los suministrados por el usuario son compatibles, pero son opcionales en condiciones normales de uso. Si no proporciona un identificador cuando añade un vértice o un borde, Neptune genera un UUID y lo convierte en una cadena, de una forma parecida a esta: `"48af8178-50ce-971a-fc41-8c9a954cea62"`. UUIDs No se ajustan al estándar RFC, por lo que si necesita un estándar, UUIDs debe generarlos externamente y proporcionarlos cuando añada vértices o aristas.
**nota**
El `Load` comando Neptune requiere que lo proporcione IDs mediante el campo **\$1id en el formato CSV** de Neptuno.
## Proporcionado por el usuario IDs
IDs Los suministrados por el usuario están permitidos en Neptune Gremlin con las siguientes estipulaciones.
+ IDs Los suministros son opcionales.
+ Solo se admiten vértices y bordes.
+ Solo se admite el tipo `String`.
Para crear un vértice con un ID personalizado, utilice el paso `property` con la palabra clave `id`: `g.addV().property(id, 'customid')`.
**nota**
No añada comillas alrededor de la palabra clave `id`. Hace referencia a `T.id`.
Todos los vértices IDs deben ser únicos y todos los bordes IDs deben ser únicos. Sin embargo, Neptune permite que un vértice y un borde tengan el mismo identificador.
Si intenta crear un vértice con `g.addV()` y ya existe un vértice con ese ID, la operación dará error. La excepción a esta norma es que, si especifica una nueva etiqueta para el vértice, la operación se completará correctamente, pero añadirá la nueva etiqueta y las propiedades adicionales especificadas al vértice existente. No se sobrescribirá ninguna. No se creará un nuevo vértice. El ID del vértice no cambia y continúa siendo único.
Por ejemplo, los siguientes comandos de la consola de Gremlin se ejecutan correctamente:
```
gremlin> g.addV('label1').property(id, 'customid')
gremlin> g.addV('label2').property(id, 'customid')
gremlin> g.V('customid').label()
==>label1::label2
```
## Propiedad del vértice IDs
IDs Las propiedades de los vértices se generan automáticamente y pueden mostrarse como números positivos o negativos cuando se consultan.
## Cardinalidad de las propiedades de vértice
Neptune admite la cardinalidad en conjuntos y la cardinalidad simple. Si no se especifica, se selecciona la cardinalidad en conjuntos. Esto significa que si establece un valor de propiedad, añade un nuevo valor a la propiedad, pero solo si este no aparece en el conjunto de valores. Este es el valor de enumeración de Gremlin de [Set (Establecer)](https://tinkerpop.apache.org/javadocs/3.7.2/core/org/apache/tinkerpop/gremlin/structure/VertexProperty.Cardinality.html).
`List` no se admite. Para obtener más información sobre la cardinalidad de las propiedades, consulte el tema de los [vértices en el Gremlin](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...-). JavaDoc
## Actualización de una propiedad de vértice
Para actualizar un valor de propiedad sin añadir un valor al conjunto de valores, especifique la cardinalidad `single` en el paso `property`.
```
g.V('exampleid01').property(single, 'age', 25)
```
Esto elimina todos los valores existentes para la propiedad.
## Etiquetas
Neptune admite varias etiquetas para un vértice. Al crear una etiqueta, puede especificar varias si las separa mediante `::`. Por ejemplo, `g.addV("Label1::Label2::Label3")` añade un vértice con tres etiquetas distintas. El paso `hasLabel` busca coincidencias de este vértice con cualquiera de esas tres etiquetas: `hasLabel("Label1")` `hasLabel("Label2")` y `hasLabel("Label3")`.
**importante**
El delimitador `::` está reservado solo para este uso. No se pueden especificar varias etiquetas en el paso `hasLabel`. Por ejemplo, `hasLabel("Label1::Label2")` no tiene ninguna coincidencia.
## Caracteres de escape
Neptune resuelve todos los caracteres de escape tal y como se describe en la sección [Escaping Special Characters]( http://groovy-lang.org/syntax.html#_escaping_special_characters) de la documentación del lenguaje Apache Groovy.
## Limitaciones de Groovy
Neptune no admite los comandos de Groovy que no empiezan por `g`. Esto incluye expresiones matemáticas (por ejemplo, `1+1`), llamadas al sistema (por ejemplo, `System.nanoTime()`) y definiciones de variable (por ejemplo, `1+1`).
**importante**
Neptune no admite nombres completos de clase. Por ejemplo, debe utilizar `single` y no `org.apache.tinkerpop.gremlin.structure.VertexProperty.Cardinality.single` en la solicitud de Groovy.
## Serialización
Neptune admite las siguientes serializaciones en función del tipo MIME solicitado.
Neptune expone todos los serializadores que lo TinkerPop hacen, con soporte para las distintas versiones y configuraciones de GraphSon y. GraphBinary A pesar de que son muchas las opciones disponibles, las instrucciones sobre cuál utilizar son muy sencillas:
+ Si utiliza TinkerPop controladores Apache, prefiera el controlador predeterminado sin especificar ninguno de forma explícita. A menos que tenga una razón muy específica para hacerlo, es probable que no necesite especificar el serializador en la inicialización del controlador. En general, el valor predeterminado que utilizan los controladores es `application/vnd.graphbinary-v1.0`.
+ Si se conecta a Neptune a través de HTTP, priorice el uso de `application/vnd.gremlin-v3.0+json;types=false`, ya que los tipos incrustados en la versión alternativa de GraphSON 3 dificultan el trabajo.
+ Por lo general, `application/vnd.graphbinary-v1.0-stringd` solo es útil cuando se usa junto con la [Consola de Gremlin](https://docs.aws.amazon.com//neptune/latest/userguide/access-graph-gremlin-console.html), ya que convierte todos los resultados en una representación de cadena para facilitar su visualización.
+ Los demás formatos se mantienen por motivos de compatibilidad con las versiones anteriores y, por lo general, no deben usarse con controladores a menos que existe una causa clara para ello.
| | | |
| --- |--- |--- |
| Tipo MIME | Serialización | Configuración |
| `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(solo funciona 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 tabla de serializadores que se muestra aquí se refiere a la nomenclatura a partir de TinkerPop la versión 3.7.0. [Si desea obtener más información sobre este cambio, consulte la TinkerPop documentación de actualización.](https://tinkerpop.apache.org/docs/current/upgrade/#_serializer_renaming) La compatibilidad con la serialización de Gyro quedó obsoleto en la versión 3.4.3 y se eliminó oficialmente en la versión 3.6.0. Si utilizas Gryo de forma explícita o utilizas una versión de controlador que lo utiliza de forma predeterminada, deberías cambiar a tu controlador GraphBinary o actualizarlo.
## Pasos de Lambda
Neptune no admite los pasos de Lambda.
## Métodos de Gremlin no admitidos
Neptune no admite los siguientes métodos de Gremlin:
+ `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)`
Por ejemplo, el recorrido siguiente no está permitido: `g.V().addE('something').from(__.V().next()).to(__.V().next())`.
**importante**
Esto ***solo*** se aplica a aquellos casos en los que envíe la consulta de Gremlin como una ***cadena de texto***.
## Pasos de Gremlin no admitidos
Neptune no admite los siguientes pasos de Gremlin:
+ El [paso io()](http://tinkerpop.apache.org/docs/3.7.2/reference/#io-step) de Gremlin solo se admite parcialmente en Neptune. Se puede usar en un contexto de lectura, como en `g.io((url)).read()`, pero no para escribir.
## Características de gráficos de Gremlin en Neptune
La implementación de Gremlin en Neptune no expone el objeto `graph`. Las siguientes tablas muestran las características de Gremlin e indican si Neptune las admite o no.
### Compatibilidad de Neptune con características de `graph`
Las características de gráficos, si se admiten, son las mismas que devolvería el comando `graph.features()`.
|
|
| Característica de gráfico | ¿Habilitada? |
| --- |--- |
| Transactions | true |
| ThreadedTransactions | false |
| Computer | false |
| Persistence | true |
| ConcurrentAccess | true |
### Compatibilidad de Neptune con características de variables
|
|
| Característica de variable | ¿Habilitada? |
| --- |--- |
| 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 |
### Compatibilidad de Neptune con características de vértices
|
|
| Característica de vértice | ¿Habilitada? |
| --- |--- |
| 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 |
### Compatibilidad de Neptune con características de propiedades de vértices
|
|
| Característica de propiedad de vértice | ¿Habilitada? |
| --- |--- |
| 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 |
### Compatibilidad de Neptune con características de bordes
|
|
| Característica de borde | ¿Habilitada? |
| --- |--- |
| AddEdges | true |
| RemoveEdges | true |
| UserSuppliedIds | true |
| AddProperty | true |
| RemoveProperty | true |
| NumericIds | false |
| StringIds | true |
| UuidIds | false |
| CustomIds | false |
| AnyIds | false |
### Compatibilidad de Neptune con características de propiedades de bordes
|
|
| Característica de propiedad de borde | ¿Habilitada? |
| --- |--- |
| 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 |
# Conformidad con los estándares de SPARQL en Amazon Neptune
Tras enumerar los estándares de SPARQL aplicables, en las siguientes secciones se proporcionan detalles específicos sobre cómo la implementación de SPARQL de Neptune amplía o se aparta de dichos estándares.
**Topics**
+ [Estándares aplicables de SPARQL](#feature-sparql-applicable-standards)
+ [Prefijos de espacio de nombres predeterminados en Neptune SPARQL](#sparql-default-prefixes)
+ [Gráfico predeterminado SPARQL y gráficos con nombre](#sparql-default-graph)
+ [Funciones del XPath constructor SPARQL compatibles con Neptune](#access-graph-sparql-xpath-constructors)
+ [IRI base predeterminado para consultas y actualizaciones](#opencypher-compliance-default-iri)
+ [Valores xsd:dateTime en Neptune](#access-graph-sparql-xsd-date-time)
+ [Gestión de Neptune de los valores especiales de coma flotante](#feature-overview-special-values-comparisons)
+ [Limitación en Neptune de los valores de longitud arbitraria](#feature-overview-arbitrary-length-values)
+ [Neptune amplía la comparación de valores iguales en SPARQL](#feature-overview-sparql-not-equal)
+ [Manejo de Out-of-Range literales en Neptune SPARQL](#feature-overview-sparql-out-of-range)
Amazon Neptune cumple los siguientes estándares en la implementación del lenguaje de consulta de gráficos SPARQL.
## Estándares aplicables de SPARQL
+ SPARQL se define en la recomendación [Lenguaje de consulta SPARQL 1.1](https://www.w3.org/TR/sparql11-query/) del W3C del 21 de marzo de 2013.
+ El lenguaje de consulta y el protocolo de SPARQL Update están definidos en la especificación [SPARQL 1.1 Update](https://www.w3.org/TR/sparql11-update/) del W3C.
+ En el caso de los formatos numéricos, SPARQL sigue la especificación de [W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes](https://www.w3.org/TR/xmlschema11-2/), que es coherente con la especificación IEEE 754 ([Estándar IEEE 754-2019 - IEEE para aritmética de coma flotante](https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html); consulte también la [página de la Wikipedia sobre IEEE 754](https://en.wikipedia.org/wiki/IEEE_754)). Sin embargo, las características que se incorporaron después de la versión `IEEE 754-1985` no están incluidas en la especificación.
## Prefijos de espacio de nombres predeterminados en Neptune SPARQL
Neptune define los siguientes prefijos de forma predeterminada para su uso en consultas de SPARQL. Para obtener más información, consulte [Nombres con prefijos](https://www.w3.org/TR/sparql11-query/#prefNames) en la especificación de 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#`
## Gráfico predeterminado SPARQL y gráficos con nombre
Amazon Neptune asocia cada triple con un gráfico con nombre. El gráfico predeterminado se define como la unión de todos los gráficos con nombre.
**Gráfico predeterminado para consultas**
Si envía una consulta SPARQL sin especificar explícitamente un gráfico mediante la palabra clave `GRAPH` o construcciones como `FROM NAMED`, Neptune siempre tiene en cuenta todos los triples en su instancia de base de datos. Por ejemplo, la siguiente consulta devuelve todos los triples desde un punto de conexión de SPARQL de Neptune:
`SELECT * WHERE { ?s ?p ?o }`
Los triples que aparecen en más de un gráfico se devuelven solo una vez.
Para obtener información sobre la especificación de gráfico predeterminado, consulte la sección [Conjunto de datos de RDF](https://www.w3.org/TR/sparql11-query/#rdfDataset) de la especificación del lenguaje de consulta SPARQL 1.1.
**Especificación del gráfico con nombre para carga, inserciones o actualizaciones**
Si no especifica un gráfico con nombre al cargar, insertar o actualizar triples, Neptune utiliza el gráfico con nombre alternativo definido por el URI `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`.
Cuando emite una solicitud `Load` de Neptune utilizando un formato basado en triples, se puede especificar el gráfico con nombre que se va a utilizar para todos los triples mediante el parámetro `parserConfiguration: namedGraphUri`. Para obtener información acerca de la sintaxis del comando `Load`, consulte [Comando del programa de carga de Neptune](load-api-reference-load.md).
**importante**
Si no utiliza este parámetro y no especifica un gráfico con nombre, se utiliza la URI alternativa: `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`.
También se utiliza este gráfico con nombre alternativo si se cargan triples a través de `SPARQL UPDATE` sin proporcionar explícitamente un destino de gráfico con nombre.
Puede utilizar el formato N-Quads basado en cuádruples para especificar un gráfico con nombre para cada triple en la base de datos.
**nota**
El uso de N-Quads le permite dejar el gráfico con nombre en blanco. En este caso, se usa `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`.
Puede anular el gráfico con nombre predeterminado para N-Quads con la opción de configuración del analizador `namedGraphUri`.
## Funciones del XPath constructor SPARQL compatibles con Neptune
El estándar SPARQL permite que los motores SPARQL admitan un conjunto extensible de funciones constructoras. XPath Neptune admite actualmente las siguientes funciones de constructores, donde el prefijo `xsd` se define como `http://www.w3.org/2001/XMLSchema#`:
+ `xsd:boolean`
+ `xsd:integer`
+ `xsd:double`
+ `xsd:float`
+ `xsd:decimal`
+ `xsd:long`
+ `xsd:unsignedLong`
## IRI base predeterminado para consultas y actualizaciones
Como un clúster de Neptune tiene varios puntos finales diferentes, utilizar la URL de solicitud de una consulta o actualización como IRI base podría generar resultados inesperados al resolver un problema relativo. IRIs
A partir de la [versión 1.2.1.0 del motor](engine-releases-1.2.1.0.md), Neptune utiliza `http://aws.amazon.com/neptune/default/` como IRI base si no hay una IRI base explícita que forme parte de la solicitud.
En la siguiente solicitud, el IRI base forma parte de la solicitud:
```
BASE
INSERT DATA { "n1" }
BASE
SELECT * { ?p ?o }
```
Y el resultado sería:
```
?p ?o
http://example.org/default/id n1
```
Sin embargo, en esta solicitud no se incluye ningún IRI base:
```
INSERT DATA { "n1" }
SELECT * { ?p ?o }
```
En ese caso, el resultado sería:
```
?p ?o
http://aws.amazon.com/neptune/default/id n1
```
## Valores xsd:dateTime en Neptune
Por motivos de rendimiento, Neptune siempre almacena date/time los valores como hora universal coordinada (UTC). Esto hace que las comparaciones directas sean muy eficientes.
Esto también significa que, si introduce un valor `dateTime` que especifica una zona horaria determinada, Neptune traduce el valor a UTC y descarta esa información de zona horaria. A continuación, cuando recupere el valor `dateTime` más tarde, se expresará en UTC, no en la hora de la zona horaria original, y no podrá indicar cuál era la zona horaria original.
## Gestión de Neptune de los valores especiales de coma flotante
Neptune gestiona los valores especiales de coma flotante en SPARQL de la siguiente manera.
### Gestión de NaN de SPARQL en Neptune
En Neptune, SPARQL puede aceptar un valor de `NaN` en una consulta. No se hace ninguna distinción entre los valores de señalización y los valores `NaN` silenciosos. Neptune trata todos los valores `NaN` como silenciosos.
Semánticamente, no es posible ninguna comparación de un valor `NaN`, porque nada es mayor, menor o igual que `NaN`. Esto significa que un valor de `NaN` en un lado de una comparación en teoría nunca coincide con *nada* del otro lado.
Sin embargo, la [especificación XSD](https://www.w3.org/TR/xmlschema-2/#double) trata dos valores `xsd:double` o `xsd:float` de `NaN` como iguales. Neptune hace esto para el filtro `IN`, para el operador igual en las expresiones de filtro y para la semántica de coincidencia (que tiene a `NaN` en la posición del objeto de un patrón triple).
### Gestión de valores infinitos de SPARQL en Neptune
En Neptune, SPARQL puede aceptar un valor de `INF` o `-INF` en una consulta. `INF` es mayor que cualquier otro valor numérico y `-INF` es menor que cualquier otro valor numérico.
Dos valores INF con signos coincidentes se comparan como iguales entre sí independientemente del tipo (por ejemplo, un flotante `-INF` se compara como igual a un `-INF` doble).
Por supuesto, no es posible ninguna comparación con `NaN` porque nada es mayor, menor o igual que `NaN`.
### Gestión de cero negativo de SPARQL en Neptune
Neptune normaliza un valor cero negativo a un cero sin signo. Puede utilizar los valores cero negativos se pueden utilizar en una consulta, pero no se registran como tales en la base de datos y se comparan como iguales a ceros sin signo.
## Limitación en Neptune de los valores de longitud arbitraria
Neptune limita el tamaño de almacenamiento de valores de enteros, coma flotante y decimales XSD en SPARQL a 64 bits. Si se utilizan valores mayores, se producirá un error `InvalidNumericDataException`.
## Neptune amplía la comparación de valores iguales en SPARQL
El estándar SPARQL define una lógica ternaria para las expresiones de valor, donde una expresión de valor puede evaluar a `true`, `false` o `error`. La semántica predeterminada para la igualdad de términos, tal y como se define en la [especificación SPARQL 1.1](https://www.w3.org/TR/sparql11-query/#func-RDFterm-equal), que se aplica a las comparaciones `=` y `!=` en las condiciones `FILTER`, produce un `error` al comparar los tipos de datos que no son explícitamente comparables en la [tabla de operadores](https://www.w3.org/TR/sparql11-query/#OperatorMapping) de la especificación.
Este comportamiento puede conllevar resultados poco intuitivos, como en el siguiente ejemplo.
Datos:
```
"127.0.0.1"^^
```
Consulta 1:
```
SELECT * WHERE {
?o .
FILTER(?o = "127.0.0.2"^^)
}
```
Consulta 2:
```
SELECT * WHERE {
?o .
FILTER(?o != "127.0.0.2"^^)
}
```
Con la semántica de SPARQL predeterminada que Neptune usaba antes de la versión 1.0.2.1, ambas consultas devolverían el resultado vacío. La razón es que, cuando `?o = "127.0.0.2"^^` se evalúa para `?o := "127.0.0.1"^^`, se produce un `error` distinto de `false` porque no hay reglas de comparación explícitas especificadas para el tipo de datos personalizados ``. Como resultado, la versión negada en la segunda consulta también produce un `error`. En ambas consultas, el `error` provoca que se excluya la solución candidata.
A partir de la versión 1.0.2.1, Neptune ha ampliado el operador de desigualdad de SPARQL de acuerdo con la especificación. Consulte la sección [SPARQL 1.1 sobre la extensibilidad de operadores](https://www.w3.org/TR/sparql11-query/#operatorExtensibility), que permite a los motores definir reglas adicionales sobre cómo efectuar la comparación entre tipos de datos integrados definidos por el usuario y no comparables.
Mediante esta opción, Neptune ahora trata una comparación de dos tipos de datos cualesquiera que no estén explícitamente definidos en la tabla de mapeo de operadores como si se evaluaran en `true` si los valores literales y los tipos de datos son sintácticamente iguales y en false en caso contrario. En cualquier caso no se produce un `error`.
Con esta nueva semántica, la segunda consulta devolvería `"127.0.0.1"^^` en lugar de un resultado vacío.
## Manejo de Out-of-Range literales en Neptune SPARQL
La semántica XSD define cada tipo numérico con su espacio de valor, excepto para `integer` y `decimal`. Estas definiciones limitan cada tipo a un rango de valores. Por ejemplo, el rango de un rango `xsd:byte` va de -128 a \$1127, ambos incluidos. Cualquier valor fuera de este rango no se considera válido.
Si intenta asignar un valor literal fuera del espacio de valores de un tipo (por ejemplo, si intenta establecer un `xsd:byte` valor literal de 999), Neptune acepta el out-of-range valor tal cual, sin redondearlo ni truncarlo. Pero no lo conserva como un valor numérico ya que el tipo determinado no puede representarlo.
Es decir, Neptune acepta `"999"^^xsd:byte` aunque sea un valor fuera del rango de valores `xsd:byte` definido. Sin embargo, después de que el valor se conserve en la base de datos, solo se puede utilizar en la semántica de coincidencia exacta, en una posición de objeto de un patrón triple. No se puede ejecutar ningún filtro de rango en él porque los out-of-range literales no se tratan como valores numéricos.
La especificación SPARQL 1.1 define [operadores de rango](https://www.w3.org/TR/sparql11-query/#OperatorMapping) con el formato `numeric`*-operador-*`numeric`, `string`*-operador-*`string`, `literal`*-operador-*`literal`, etc. Neptune no puede ejecutar un operador de comparación de rangos con algo como `invalid-literal`*-operador-*`numeric-value`.
# Conformidad con la especificación de openCypher en Amazon Neptune
La versión de openCypher de Amazon Neptune suele admitir las cláusulas, los operadores, las expresiones, las funciones y la sintaxis que se definen en la especificación de openCypher actual, que es [Cypher Query Language Reference Version 9](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf). A continuación, se detallan las limitaciones y diferencias en la compatibilidad de Neptune con openCypher.
Amazon Neptune también admite varias características que van más allá del alcance de la especificación de openCypher. Consulte [Extensiones de openCypher en Amazon Neptune](access-graph-opencypher-extensions.md) para obtener más información.
**nota**
La implementación actual de Neo4j de Cypher contiene una funcionalidad que no está incluida en la especificación de openCypher mencionada anteriormente. Si va a migrar el código de Cypher actual a Neptune, consulte [Compatibilidad de Neptune con Neo4j](migration-compatibility.md) y [Reescritura de consultas de Cypher para ejecutarlas en openCypher en Neptune](migration-opencypher-rewrites.md) para obtener más información.
## Compatibilidad con las cláusulas de openCypher en Neptune
Neptune admite las siguientes cláusulas, salvo que se indique lo contrario:
+ `MATCH`: se admite, pero *`shortestPath()`* y *`allShortestPaths()`* no se admiten en este momento.
+ `OPTIONAL MATCH`
+ *`MANDATORY MATCH`*: **no** se admite en este momento en Neptune. Sin embargo, Neptune admite [valores de ID personalizados](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids) en las consultas `MATCH`.
+ `RETURN`: se admite, excepto cuando se utiliza con valores no estáticos para `SKIP` o `LIMIT`. Por ejemplo, lo siguiente no funciona actualmente:
```
MATCH (n)
RETURN n LIMIT toInteger(rand()) // Does NOT work!
```
+ `WITH`: se admite, excepto cuando se utiliza con valores no estáticos para `SKIP` o `LIMIT`. Por ejemplo, lo siguiente no funciona actualmente:
```
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 permite crear [valores de identificadores personalizados](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids) en las consultas `CREATE`.
+ `DELETE`
+ `SET`
+ `REMOVE`
+ `MERGE`: Neptune admite [valores de identificadores personalizados](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids) en las consultas `MERGE`.
+ *`CALL[YIELD...]`*: **no** se admite en este momento en Neptune.
+ `UNION, UNION ALL`: se admiten consultas de solo lectura, pero actualmente **no** se admiten consultas de mutación.
+ `USING`: `USING` es compatible con la versión [1.3.2.0](https://docs.aws.amazon.com//neptune/latest/userguide/engine-releases-1.3.2.0.html) del motor. Para obtener más información, consulte [Sugerencias de consulta](https://docs.aws.amazon.com//neptune/latest/userguide/opencypher-query-hints.html).
## Compatibilidad con las operadores de openCypher en Neptune
Neptune admite los siguientes operadores, salvo que se indique lo contrario:
**Operadores generales**
+ `DISTINCT`
+ El operador `.` para acceder a las propiedades de un mapa literal anidado.
**Operadores matemáticos**
+ El operador de suma `+`.
+ El operador de resta `-`.
+ El operador de multiplicación `*`.
+ El operador de división `/`.
+ El operador de división de módulo `%`.
+ El operador de `^` exponenciación. *is NOT supported*
**Operadores de comparación**
+ El operador de suma `=`.
+ El operador de desigualdad `<>`.
+ Se admite el operador menor que `<`, excepto cuando alguno de los argumentos es una ruta, una lista o un mapa.
+ Se admite el operador mayor que `>`, excepto cuando alguno de los argumentos es una ruta, una lista o un mapa.
+ Se admite el operador `<=` less-than-or-equal -to excepto cuando alguno de los argumentos es una ruta, una lista o un mapa.
+ Se admite el operador `>=` greater-than-or-equal -to excepto cuando alguno de los argumentos es una ruta, una lista o un mapa.
+ `IS NULL`
+ `IS NOT NULL`
+ `STARTS WITH` se admite si los datos que se buscan son una cadena.
+ `ENDS WITH` se admite si los datos que se buscan son una cadena.
+ `CONTAINS` se admite si los datos que se buscan son una cadena.
**Operadores booleanos**
+ `AND`
+ `OR`
+ `XOR`
+ `NOT`
**Operadores de cadena**
+ El operador de concatenación `+`.
**Operadores de lista**
+ El operador de concatenación `+`.
+ `IN` (comprueba la presencia de un elemento en una lista)
## Compatibilidad con expresiones de openCypher en Neptune
Neptune admite las siguientes expresiones, salvo que se indique lo contrario:
+ `CASE`
+ La expresión `[]` **no** se admite actualmente en Neptune para acceder a claves de propiedad calculadas dinámicamente dentro de un nodo, una relación o un mapa. Por ejemplo, lo siguiente no funciona:
```
MATCH (n)
WITH [5, n, {key: 'value'}] AS list
RETURN list[1].name
```
## Compatibilidad con las funciones de openCypher en Neptune
Neptune admite las siguientes funciones, salvo que se indique lo contrario:
**Funciones de predicados**
+ `exists()`
**Funciones escalares**
+ `coalesce()`
+ `endNode()`
+ `epochmillis()`
+ `head()`
+ `id()`
+ `last()`
+ `length()`
+ `randomUUID()`
+ `properties()`
+ `removeKeyFromMap`
+ `size()`: este método sobrecargado solo funciona actualmente para expresiones de patrones, listas y cadenas
+ `startNode()`
+ `timestamp()`
+ `toBoolean()`
+ `toFloat()`
+ `toInteger()`
+ `type()`
**Funciones de agregación**
+ `avg()`
+ `collect()`
+ `count()`
+ `max()`
+ `min()`
+ `percentileDisc()`
+ `stDev()`
+ `percentileCont()`
+ `stDevP()`
+ `sum()`
**Lista de funciones**
+ [`join()`](access-graph-opencypher-extensions.md#opencypher-compliance-join-function) (concatena las cadenas de una lista en una sola cadena)
+ `keys()`
+ `labels()`
+ `nodes()`
+ `range()`
+ `relationships()`
+ `reverse()`
+ `tail()`
**Funciones matemáticas: numéricas**
+ `abs()`
+ `ceil()`
+ `floor()`
+ `rand()`
+ `round()`
+ `sign()`
**Funciones matemáticas: logarítmicas**
+ `e()`
+ `exp()`
+ `log()`
+ `log10()`
+ `sqrt()`
**Funciones matemáticas: trigonométricas**
+ `acos()`
+ `asin()`
+ `atan()`
+ `atan2()`
+ `cos()`
+ `cot()`
+ `degrees()`
+ `pi()`
+ `radians()`
+ `sin()`
+ `tan()`
**Funciones de cadena**
+ [`join()`](access-graph-opencypher-extensions.md#opencypher-compliance-join-function) (concatena las cadenas de una lista en una sola cadena)
+ `left()`
+ `lTrim()`
+ `replace()`
+ `reverse()`
+ `right()`
+ `rTrim()`
+ `split()`
+ `substring()`
+ `toLower()`
+ `toString()`
+ `toUpper()`
+ `trim()`
**Funciones definidas por el usuario**
*User-defined functions*actualmente **no** son compatibles con Neptune.
## Detalles de la implementación de openCypher específica de Neptune
En las siguientes secciones, se describen las formas en las que la implementación de openCypher de Neptune puede diferir o ir más allá de las [especificaciones de openCypher](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf).
### Evaluaciones de la ruta de longitud variable (VLP) en Neptune
Las evaluaciones de rutas de longitud variable (`VLP`) detectan rutas entre nodos en el gráfico. La longitud de la ruta no puede estar restringida en una consulta. Para evitar ciclos, en la [especificación de openCypher](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf) se indica que cada borde debe recorrerse como máximo una vez por solución.
Pues VLPs, la implementación de Neptune se desvía de la especificación OpenCypher en el sentido de que solo admite valores constantes para los filtros de igualdad de propiedades. Tomemos como ejemplo la siguiente consulta:
```
MATCH (x)-[:route*1..2 {dist:33, code:x.name}]->(y) return x,y
```
Dado que el valor del filtro de igualdad de la propiedad `x.name` no es una constante, esta consulta da como resultado una `UnsupportedOperationException` con el mensaje: `Property predicate over variable-length relationships with non-constant expression is not supported in this release.`
### Compatibilidad temporal en la implementación de openCypher de Neptune (Neptune Database 1.3.1.0 y anteriores)
Actualmente, Neptune proporciona una compatibilidad limitada con la función temporal en openCypher. Admite el tipo de datos `DateTime` para los tipos temporales.
La función `datetime()` se puede utilizar para obtener la fecha y hora UTC actuales de la siguiente manera:
```
RETURN datetime() as res
```
Los valores de fecha y hora se pueden analizar a partir de cadenas en un formato de `"`*fecha*`T`*hora*`"` en el que la *fecha* y la *hora* se expresan en uno de los formatos admitidos que se indican a continuación:
**Formatos de fecha admitidos**
+ `yyyy-MM-dd`
+ `yyyyMMdd`
+ `yyyy-MM`
+ `yyyy-DDD`
+ `yyyyDDD`
+ `yyyy`
**Formatos de tiempo admitidos**
+ `HH:mm:ssZ`
+ `HHmmssZ`
+ `HH:mm:ssZ`
+ `HH:mmZ`
+ `HHmmZ`
+ `HHZ`
+ `HHmmss`
+ `HH:mm:ss`
+ `HH:mm`
+ `HHmm`
+ `HH`
Por ejemplo:
```
RETURN datetime('2022-01-01T00:01') // or another example:
RETURN datetime('2022T0001')
```
Tenga en cuenta que todos date/time los valores de Neptune OpenCypher se almacenan y recuperan como valores UTC.
openCypher de Neptune usa un reloj `statement`, lo que significa que se usa el mismo instante en el tiempo durante toda la consulta. Una consulta diferente dentro de la misma transacción podría utilizar un instante diferente en el tiempo.
Neptune no admite el uso de una función en una llamada a `datetime()`. Por ejemplo, lo siguiente no funciona:
```
CREATE (:n {date:datetime(tostring(2021))}) // ---> NOT ALLOWED!
```
Neptune admite la función `epochmillis()` que convierte una `datetime` en `epochmillis`. Por ejemplo:
```
MATCH (n) RETURN epochMillis(n.someDateTime)
1698972364782
```
Neptune no admite actualmente otras funciones y operaciones en objetos `DateTime`, como la suma y la resta.
### Compatibilidad temporal en la implementación de openCypher con Neptune (Neptune Analytics y Neptune Database 1.3.2.0 y posteriores)
La siguiente funcionalidad de fecha y hora OpenCypher se aplica a Neptune Analytics. Como alternativa, puede usar el parámetro de modo de laboratorio `DatetimeMillisecond=enabled` para habilitar la siguiente funcionalidad de fecha y hora en la versión 1.3.2.0 y posteriores del motor de Neptune. Para obtener más información sobre el uso de esta funcionalidad en modo de laboratorio, consulte [Compatibilidad ampliada con fecha y hora](features-lab-mode.md#labmode-extended-datetime-support).
+ Compatibilidad con milisegundos. El literal de fecha y hora siempre se devolverá con milisegundos, incluso si los milisegundos son 0. (El comportamiento anterior consistía en truncar los milisegundos).
```
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"
}
}
} ]
}
```
+ Compatibilidad con la llamada a la función datetime() sobre propiedades almacenadas o resultados intermedios. Por ejemplo, las siguientes consultas no eran posibles antes de esta característica.
Datetime() sobre propiedades:
```
// 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() sobre resultados intermedios:
```
// Parse datetime from parameter
UNWIND $list as myDate
RETURN datetime(myDate) as d
```
+ Ahora también es posible guardar propiedades de fecha y hora creadas en los casos mencionados anteriormente.
Guardar la fecha y hora de la propiedad de cadena de una propiedad a otra:
```
// 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)
```
Crear nodos por lotes a partir de un parámetro con una propiedad de fecha y hora:
```
// 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 para un subconjunto más grande de formatos de ISO8601 fecha y hora. Consulte a continuación.
Formatos admitidos
El formato de un valor de fecha y hora es [Fecha]T[Hora][Zona horaria], donde T es el separador. Si no se proporciona una zona horaria de forma explícita, se asume que UTC (Z) es la predeterminada.
Timezone
Los formatos de zona horaria admitidos son:
+ \$1/-HH:mm
+ \$1/-HHmm
+ \$1/-HH
La presencia de una zona horaria en una cadena de fecha y hora es opcional. En caso de que la diferencia de zona horaria sea 0, se puede usar Z en lugar del sufijo de zona horaria anterior para indicar la hora UTC. El rango admitido de una zona horaria es de -14:00 a \$114:00.
Date
Si no hay ninguna zona horaria o la zona horaria es UTC (Z), los formatos de fecha admitidos son los siguientes:
**nota**
DDD hace referencia a una fecha ordinal, que representa un día del año comprendido entre 001 y 365 (366 en los años bisiestos). Por ejemplo, 2024-002 representa el 2 de enero de 2024.
+ `yyyy-MM-dd`
+ `yyyyMMdd`
+ `yyyy-MM`
+ `yyyyMM`
+ `yyyy-DDD`
+ `yyyyDDD`
+ `yyyy`
Si se elige una zona horaria distinta de la Z, los formatos de fecha admitidos se limitan a los siguientes:
+ `yyyy-MM-dd`
+ `yyyy-DDD`
+ `yyyyDDD`
El rango de fechas admitido es del 1 de enero de 1400 al 31 de enero de 9999.
Time
Si no hay ninguna zona horaria o la zona horaria es UTC (Z), los formatos de hora admitidos son:
+ `HH:mm:ss.SSS`
+ `HH:mm:ss`
+ `HHmmss.SSS`
+ `HHmmss`
+ `HH:mm`
+ `HHmm`
+ `HH`
Si se elige una zona horaria distinta de la Z, los formatos de hora admitidos se limitan a los siguientes:
+ `HH:mm:ss`
+ `HH:mm:ss.SSS`
### Diferencias en la semántica del lenguaje openCypher de Neptune
Neptune representa el nodo y la relación IDs como cadenas en lugar de números enteros. El identificador es igual al identificador proporcionado a través del programa de carga de datos. Si hay un espacio de nombres para la columna, se utiliza el espacio de nombres más el identificador. En consecuencia, la función `id` devuelve una cadena en lugar de un número entero.
El tipo de datos `INTEGER` está limitado a 64 bits. Al convertir valores de cadena o coma flotante más grandes en un número entero mediante la función `TOINTEGER`, los valores negativos se truncan a `LLONG_MIN` y los valores positivos se truncan a `LLONG_MAX`.
Por ejemplo:
```
RETURN TOINTEGER(2^100)
> 9223372036854775807
RETURN TOINTEGER(-1 * 2^100)
> -9223372036854775808
```
### Propiedades de varios valores
Aunque CREATE de openCypher no crea propiedades con varios valores, sí que pueden existir en los datos creados con Gremlin (Neptune Database) o al cargar datos (Neptune Database y Neptune Analytics). Si openCypher de Neptune encuentra una propiedad con varios valores, uno de los valores se elige arbitrariamente, lo que da lugar a un resultado no determinista.
### Gestión de valores NaN
La gestión que Neptune hace de la comparación de valores de propiedad `NaN` no está definida. Basarse en tales comparaciones puede dar lugar a resultados inesperados o no deterministas.