As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Observações sobre conformidade com os padrões do Amazon Neptune
O Amazon Neptune está em conformidade com os padrões aplicáveis na implementação das linguagens de consulta do grafo Gremlin e SPARQL na maioria dos casos.
Estas seções descrevem os padrões, bem como as áreas em que o Neptune os amplia ou diverge deles.
**Topics**
+ [Conformidade com os padrões do Gremlin no Amazon Neptune](access-graph-gremlin-differences.md)
+ [Conformidade com os padrões SPARQL no Amazon Neptune](feature-sparql-compliance.md)
+ [Conformidade com especificações do openCypher no Amazon Neptune](feature-opencypher-compliance.md)
# Conformidade com os padrões do Gremlin no Amazon Neptune
As seções a seguir fornecem uma visão geral da implementação do Gremlin no Neptune e como ela difere da implementação do Apache. TinkerPop
O Neptune implementa algumas etapas do Gremlin nativamente em seu mecanismo e usa a implementação do TinkerPop Apache Gremlin para processar outras (consulte). [Suporte nativo para etapas do Gremlin no Amazon Neptune](gremlin-step-support.md)
**nota**
Para obter exemplos concretos dessas diferenças de implementação mostradas no console do Gremlin e no Amazon Neptune, consulte a seção [Usar o Gremlin para acessar os dados de grafo no Amazon Neptune](get-started-graph-gremlin.md) do Quick Start.
**Topics**
+ [Padrões aplicáveis para Gremlin](#feature-gremlin-applicable-standards)
+ [Variáveis e parâmetros em scripts](#feature-gremlin-differences-variables)
+ [TinkerPop enumerações](#feature-gremlin-differences-tinkerpop)
+ [Código Java](#feature-gremlin-differences-java)
+ [Propriedades em elementos](#feature-gremlin-differences-properties-on-elements)
+ [Execução do script](#feature-gremlin-differences-script)
+ [Sessões](#feature-gremlin-differences-sessions)
+ [Transações](#feature-gremlin-differences-transactions)
+ [Vértice e borda IDs](#feature-gremlin-differences-vertex-edge-ids)
+ [Fornecido pelo usuário IDs](#feature-gremlin-differences-user-supplied-ids)
+ [Propriedade do vértice IDs](#feature-gremlin-differences-vertex-property-ids)
+ [Cardinalidade de propriedades de vértice](#feature-gremlin-differences-vertex-property-cardinality)
+ [Atualizar uma propriedade de vértice](#feature-gremlin-differences-vertex-property-update)
+ [Rótulos](#feature-gremlin-differences-labels)
+ [Caracteres de escape](#feature-gremlin-differences-escapes)
+ [Limitações do Groovy](#feature-gremlin-differences-groovy)
+ [Serialização](#feature-gremlin-differences-serialization)
+ [Etapas do Lambda](#feature-gremlin-differences-lambda)
+ [Métodos do Gremlin não compatíveis](#feature-gremlin-differences-unsupported-methods)
+ [Etapas do Gremlin não compatíveis](#feature-gremlin-differences-unsupported-steps)
+ [Atributos do grafo do Gremlin no Neptune](#gremlin-api-reference-features)
## Padrões aplicáveis para Gremlin
+ A linguagem Gremlin é definida pela [ TinkerPop documentação do Apache](http://tinkerpop.apache.org/docs/current/reference/) e pela TinkerPop implementação do Gremlin pelo Apache, e não por uma especificação formal.
+ Para formatos numéricos, o Gremlin segue o padrão IEEE 754 ([IEEE 754-2019 - IEEE Standard for Floating-Point Arithmetic](https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html). Para obter mais informações, consulte também a [página do IEEE 754 na Wikipédia](https://en.wikipedia.org/wiki/IEEE_754)).
## Variáveis e parâmetros em scripts
No que diz respeito às variáveis pré-vinculadas, o objeto de percurso `g` é pré-vinculado no Neptune, e o objeto `graph` não é compatível.
Embora o Neptune não seja compatível com variáveis do Gremlin nem com a parametrização em scripts, é possível encontrar exemplos de scripts para o Gremlin Server na Internet que contêm declarações de variáveis, como:
```
String query = "x = 1; g.V(x)";
List results = client.submit(query).all().get();
```
Também há muitos exemplos que usam [parametrização](https://tinkerpop.apache.org/docs/current/reference/#parameterized-scripts) (ou vinculações) ao enviar consultas, como:
```
Map params = new HashMap<>();
params.put("x",1);
String query = "g.V(x)";
List results = client.submit(query).all().get();
```
Os exemplos de parâmetro geralmente são associados a avisos sobre penalidades de desempenho por não parametrizar quando possível. Você pode encontrar muitos exemplos desse tipo, e todos parecem bastante convincentes sobre a necessidade de parametrizar. TinkerPop
No entanto, tanto o recurso de declaração de variáveis quanto o recurso de parametrização (junto com os avisos) só se aplicam ao Gremlin Server quando TinkerPop ele está usando o. `GremlinGroovyScriptEngine` Eles não se aplicam quando o Gremlin Server usa a gramática `gremlin-language` ANTLR do Gremlin para analisar consultas. A gramática ANTLR não aceita declarações de variáveis nem parametrização, portanto, ao usar o ANTLR, você não precisa se preocupar em deixar de parametrizar. Como a gramática ANTLR é um componente mais recente TinkerPop, o conteúdo mais antigo que você pode encontrar na Internet geralmente não reflete essa distinção.
O Neptune usa a gramática ANTLR no mecanismo de processamento de consultas em vez do `GremlinGroovyScriptEngine`, portanto, não é compatível com variáveis, parametrização nem com a propriedade `bindings`. Como resultado, os problemas relacionados à falha na parametrização não se aplicam ao Neptune. Usando o Neptune, é perfeitamente seguro simplesmente enviar a consulta como está, onde normalmente seria parametrizada. Como resultado, o exemplo anterior pode ser simplificado sem penalidades de desempenho da seguinte forma:
```
String query = "g.V(1)";
List results = client.submit(query).all().get();
```
## TinkerPop enumerações
O Neptune não é compatível com nomes de classes totalmente qualificados para valores de enumeração. Por exemplo, você deve usar `single` e não `org.apache.tinkerpop.gremlin.structure.VertexProperty.Cardinality.single` na solicitação do Groovy.
O tipo de enumeração é determinado pelo tipo do parâmetro.
A tabela a seguir mostra os valores de enumeração permitidos e o nome TinkerPop totalmente qualificado relacionado.
| Valores permitidos | 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.Cardinalidade](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.Barreira](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.Escolha](https://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/process/traversal/Pick.html) |
## Código Java
O Neptune não suporta chamadas para métodos definidos por chamadas arbitrárias de Java ou de bibliotecas Java que não sejam chamadas do Gremlin compatível. APIs Por exemplo `java.lang.*`, `Date()` e `g.V().tryNext().orElseGet()` não são permitidos.
## Propriedades em elementos
Neptune não suporta `materializeProperties` o sinalizador que foi introduzido TinkerPop na versão 3.7.0 para retornar propriedades em elementos. Como resultado, o Neptune retornará somente vértices ou bordas como referências com somente seu `id` e `label`.
## Execução do script
Todas as consultas devem começar com `g`, o objeto de percurso.
Em envios de consulta de string, é possível emitir vários percursos separados por ponto-e-vírgula (`;`) ou um caractere de nova linha (`\n`). Para ser executada, cada instrução que não seja a última deve terminar com uma etapa `.iterate()`. Somente os dados de percurso final são retornados. Observe que isso não se aplica aos envios de ByteCode consultas GLV.
## Sessões
As sessões no Neptune se limitam a apenas dez minutos de duração. Consulte [Sessões baseadas em script do Gremlin](access-graph-gremlin-sessions.md) a [Referência da TinkerPop sessão](https://tinkerpop.apache.org/docs/current/reference/#console-sessions) para obter mais informações.
## Transações
O Neptune abre uma nova transação no início de cada percurso do Gremlin e fecha a transação após a conclusão bem-sucedida do percurso. A operação é revertida quando há um erro.
Várias instruções separadas por um ponto-e-vírgula (`;`) ou um caractere de nova linha (`\n`) são incluídos em uma única transação. Cada instrução diferente da última deve terminar com uma etapa `next()` a ser executada. Somente os dados de percurso final são retornados.
A lógica da transação manual que usa `tx.commit()` e `tx.rollback()` não é compatível.
**Importante**
Isso se aplica ***somente*** a métodos nos quais você envia a consulta do Gremlin como uma ***string de texto*** (consulte [Transações do Gremlin](access-graph-gremlin-transactions.md)).
## Vértice e borda IDs
Neptune Gremlin Vertex and Edge devem ser do tipo. IDs `String` Essas strings de ID são compatíveis com caracteres Unicode e não podem exceder 55 MB de tamanho.
IDs Os fornecidos pelo usuário são suportados, mas são opcionais no uso normal. Se você não fornecer um ID ao adicionar um vértice ou uma borda, o Neptune vai gerar um UUID e convertê-lo em uma string, da seguinte forma: `"48af8178-50ce-971a-fc41-8c9a954cea62"`. Eles UUIDs não estão em conformidade com o padrão RFC, portanto, se você precisar de um padrão UUIDs , deve gerá-los externamente e fornecê-los ao adicionar vértices ou arestas.
**nota**
O comando `Load` Neptune exige que você IDs forneça, usando o campo \$1id no formato **CSV do** Neptune.
## Fornecido pelo usuário IDs
IDs Os fornecidos pelo usuário são permitidos no Neptune Gremlin com as seguintes estipulações.
+ IDs Os fornecidos são opcionais.
+ Somente vértices e pontos são compatíveis.
+ Somente o tipo `String` é compatível.
Para criar um novo vértice com um ID personalizado, use a etapa `property` com a palavra-chave `id`: `g.addV().property(id, 'customid')`.
**nota**
Não coloque aspas em torno da palavra-chave `id`. Ela se refere a `T.id`.
Todo vértice IDs deve ser exclusivo e toda borda IDs deve ser exclusiva. O Neptune, no entanto, permite que um vértice e uma borda tenham o mesmo ID.
Se você tentar criar um novo vértice usando o `g.addV()` e já existir um vértice com esse ID, haverá falha na operação. A exceção para isso é que, se você especificar um novo rótulo para o vértice, a operação terá êxito, mas adiciona o novo rótulo e quaisquer propriedades adicionais especificadas ao vértice existente. Nada é substituído. Um novo vértice não é criado. O ID do vértice não altera e permanece exclusivo.
Por exemplo, os comandos a seguir do Gremlin Console serão bem-sucedidos:
```
gremlin> g.addV('label1').property(id, 'customid')
gremlin> g.addV('label2').property(id, 'customid')
gremlin> g.V('customid').label()
==>label1::label2
```
## Propriedade do vértice IDs
IDs As propriedades do vértice são geradas automaticamente e podem aparecer como números positivos ou negativos quando consultadas.
## Cardinalidade de propriedades de vértice
O Neptune é compatível com a cardinalidade set e a cardinalidade single. Se não estiver especificado, a cardinalidade set será selecionada. Isso significa que, se você definir um valor para a propriedade, um novo valor será adicionado à propriedade, mas somente se ela ainda estiver exibida no conjunto de valores. Esse é o valor da enumeração do Gremlin de [Set](https://tinkerpop.apache.org/javadocs/3.7.2/core/org/apache/tinkerpop/gremlin/structure/VertexProperty.Cardinality.html).
Não há suporte ao `List`. Para obter mais informações sobre a cardinalidade da propriedade, consulte o tópico [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...-) no Gremlin. JavaDoc
## Atualizar uma propriedade de vértice
Para atualizar o valor de uma propriedade sem adicionar mais um valor ao conjunto de valores, especifique cardinalidade `single` na etapa `property`.
```
g.V('exampleid01').property(single, 'age', 25)
```
Isso remove todos os valores existentes da propriedade.
## Rótulos
O Neptune é compatível com vários rótulos para um vértice. Quando cria um rótulo, você pode especificar vários rótulos separados com `::`. Por exemplo, `g.addV("Label1::Label2::Label3")` adiciona um vértice com três diferentes rótulos. A etapa `hasLabel` corresponde esse vértice com qualquer um destes três rótulos: `hasLabel("Label1")`, `hasLabel("Label2")` e `hasLabel("Label3")`.
**Importante**
O delimitador `::` é reservado somente para esse uso. Você não pode especificar vários rótulos na etapa `hasLabel`. Por exemplo, `hasLabel("Label1::Label2")` não corresponde a nada.
## Caracteres de escape
O Neptune resolve todos os caracteres de escape, conforme descrito na seção [Escaping Special Characters]( http://groovy-lang.org/syntax.html#_escaping_special_characters) da documentação da linguagem Apache Groovy.
## Limitações do Groovy
O Neptune não é compatível com comandos do Groovy que não começam com `g`. Isso inclui matemática (por exemplo: `1+1`), chamadas do sistema (por exemplo: `System.nanoTime()`) e definições das variáveis (por exemplo: `1+1`).
**Importante**
O Neptune não é compatível com nomes de classes totalmente qualificados. Por exemplo, você deve usar `single` e não `org.apache.tinkerpop.gremlin.structure.VertexProperty.Cardinality.single` na solicitação do Groovy.
## Serialização
O Neptune é compatível com as serializações a seguir com base no tipo MIME solicitado.
O Neptune expõe todos os serializadores TinkerPop que o fazem, com suporte para as várias versões e configurações do GraphSon e. GraphBinary Apesar de haver muitas opções presentes, a orientação sobre qual usar é simples:
+ Se você estiver usando TinkerPop drivers Apache, prefira o padrão para o driver sem especificar um explicitamente. A menos que você tenha um motivo muito específico, provavelmente não precisará especificar o serializador na inicialização do driver. Em geral, o padrão usado pelos drivers é `application/vnd.graphbinary-v1.0`.
+ Se você estiver se conectando ao Neptune via HTTP, priorize usar `application/vnd.gremlin-v3.0+json;types=false`, pois os tipos incorporados na versão alternativa do GraphSON 3 dificultam o trabalho.
+ Geralmente, `application/vnd.graphbinary-v1.0-stringd` só é útil quando usado em conjunto com o [Gremlin Console](https://docs.aws.amazon.com//neptune/latest/userguide/access-graph-gremlin-console.html), pois converte todos os resultados em uma representação de string para exibição simples.
+ Os formatos restantes permanecem presentes por motivos de legado e normalmente não devem ser usados com drivers sem motivo claro.
| | | |
| --- |--- |--- |
| Tipo MIME | Serialização | Configuração |
| `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(só funciona com 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**
A tabela do serializador mostrada aqui se refere à nomenclatura a partir da versão 3.7.0. TinkerPop Se você quiser saber mais sobre essa mudança, consulte a [documentação de TinkerPop atualização](https://tinkerpop.apache.org/docs/current/upgrade/#_serializer_renaming). O suporte à serialização Gryo foi descontinuado na versão 3.4.3 e oficialmente removido na versão 3.6.0. Se você estiver usando explicitamente o Gryo ou em uma versão de driver que o usa por padrão, você deve mudar para o driver GraphBinary ou atualizá-lo.
## Etapas do Lambda
O Neptune não é compatível com as etapas do Lambda.
## Métodos do Gremlin não compatíveis
O Neptune não é compatível com os seguintes métodos do 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 exemplo, a seguinte travessia não é permitida: `g.V().addE('something').from(__.V().next()).to(__.V().next())`
**Importante**
Isso se aplica ***somente*** a métodos onde você envia a consulta Gremlin como uma ***string de texto***.
## Etapas do Gremlin não compatíveis
O Neptune não é compatível com as seguintes etapas de Gremlin:
+ A [Etapa io( )](http://tinkerpop.apache.org/docs/3.7.2/reference/#io-step) do Gremlin é compatível apenas parcialmente com o Neptune. Ela pode ser usada em um contexto de leitura, como em `g.io((url)).read()`, mas não para escrever.
## Atributos do grafo do Gremlin no Neptune
A implementação do Gremlin no Neptune não expõe o objeto `graph`. As tabelas a seguir listam os atributos do Gremlin e indicam se o Neptune é compatível ou não com eles.
### Compatibilidade do Neptune com atributos do `graph`
Os atributos de grafo do Neptune, quando compatíveis, são os mesmos que seriam gerados pelo comando `graph.features()`.
|
|
| Atributo do grafo | Habilitado? |
| --- |--- |
| Transactions | verdadeiro |
| ThreadedTransactions | false |
| Computer | false |
| Persistence | true |
| ConcurrentAccess | true |
### Compatibilidade do Neptune com atributos de variável
|
|
| Atributo de variável | Habilitado? |
| --- |--- |
| 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 |
### Compatibilidade do Neptune com atributos do vértice
|
|
| Atributo de vértice | Habilitado? |
| --- |--- |
| MetaProperties | false |
| DuplicateMultiProperties | false |
| AddVertices | true |
| RemoveVertices | true |
| MultiProperties | true |
| UserSuppliedIds | true |
| AddProperty | true |
| RemoveProperty | verdadeiro |
| NumericIds | false |
| StringIds | verdadeiro |
| UuidIds | false |
| CustomIds | false |
| AnyIds | false |
### Compatibilidade do Neptune com atributos de propriedade do vértice
|
|
| Atributo de propriedade de vértice | Habilitado? |
| --- |--- |
| UserSuppliedIds | false |
| AddProperty | true |
| RemoveProperty | true |
| NumericIds | true |
| StringIds | verdadeiro |
| UuidIds | false |
| CustomIds | false |
| AnyIds | false |
| Properties | verdadeiro |
| SerializableValues | false |
| UniformListValues | false |
| BooleanArrayValues | false |
| DoubleArrayValues | false |
| IntegerArrayValues | false |
| StringArrayValues | false |
| BooleanValues | true |
| ByteValues | true |
| DoubleValues | true |
| FloatValues | true |
| IntegerValues | true |
| LongValues | verdadeiro |
| MapValues | false |
| MixedListValues | false |
| StringValues | verdadeiro |
| ByteArrayValues | false |
| FloatArrayValues | false |
| LongArrayValues | false |
### Compatibilidade do Neptune com atributos de borda
|
|
| Atributo de borda | Habilitado? |
| --- |--- |
| AddEdges | true |
| RemoveEdges | true |
| UserSuppliedIds | true |
| AddProperty | true |
| RemoveProperty | verdadeiro |
| NumericIds | false |
| StringIds | verdadeiro |
| UuidIds | false |
| CustomIds | false |
| AnyIds | false |
### Compatibilidade do Neptune com atributos de propriedade de borda
|
|
| Atributo de propriedade de borda | Habilitado? |
| --- |--- |
| Properties | verdadeiro |
| SerializableValues | false |
| UniformListValues | false |
| BooleanArrayValues | false |
| DoubleArrayValues | false |
| IntegerArrayValues | false |
| StringArrayValues | false |
| BooleanValues | true |
| ByteValues | true |
| DoubleValues | true |
| FloatValues | true |
| IntegerValues | true |
| LongValues | verdadeiro |
| MapValues | false |
| MixedListValues | false |
| StringValues | verdadeiro |
| ByteArrayValues | false |
| FloatArrayValues | false |
| LongArrayValues | false |
# Conformidade com os padrões SPARQL no Amazon Neptune
Depois de listar os padrões SPARQL aplicáveis, as seções a seguir fornecem detalhes específicos sobre como a implementação do SPARQL no Neptune se estende ou diverge desses padrões.
**Topics**
+ [Padrões aplicáveis do SPARQL](#feature-sparql-applicable-standards)
+ [Prefixos de namespace padrão no SPARQL no Neptune](#sparql-default-prefixes)
+ [Gráfico padrão e gráficos nomeados do SPARQL](#sparql-default-graph)
+ [XPath Funções do construtor SPARQL suportadas pelo Neptune](#access-graph-sparql-xpath-constructors)
+ [IRI de base padrão para consultas e atualizações](#opencypher-compliance-default-iri)
+ [Valores xsd:dateTime no Neptune](#access-graph-sparql-xsd-date-time)
+ [Tratar valores de ponto flutuante especiais do Neptune](#feature-overview-special-values-comparisons)
+ [Limitação de valores de comprimento arbitrário do Neptune](#feature-overview-arbitrary-length-values)
+ [O Neptune estende a comparação “igual a” no SPARQL](#feature-overview-sparql-not-equal)
+ [Manipulação de Out-of-Range literais em Neptune SPARQL](#feature-overview-sparql-out-of-range)
O Amazon Neptune está em conformidade com os padrões a seguir na implementação da linguagem de consulta de grafos SPARQL.
## Padrões aplicáveis do SPARQL
+ O SPARQL é definido pela recomendação W3C [SPARQL 1.1 Query Language](https://www.w3.org/TR/sparql11-query/) de 21 de março de 2013.
+ O protocolo de atualização e a linguagem de consulta do SPARQL são definidos pela especificação W3C [SPARQL 1.1 Update](https://www.w3.org/TR/sparql11-update/).
+ Para formatos numéricos, o SPARQL segue a especificação [W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes](https://www.w3.org/TR/xmlschema11-2/), consistente com a especificação IEEE 754 ([IEEE 754-2019 - IEEE Standard for Floating-Point Arithmetic](https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html). Para obter mais informações, consulte também a [página IEEE 754 da Wikipédia](https://en.wikipedia.org/wiki/IEEE_754)). No entanto, os recursos que foram apresentados após a versão `IEEE 754-1985` não estão incluídos na especificação.
## Prefixos de namespace padrão no SPARQL no Neptune
O Neptune define os prefixos a seguir por padrão para uso em consultas do SPARQL. Para obter mais informações, consulte [Nomes prefixados](https://www.w3.org/TR/sparql11-query/#prefNames) na especificação do 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 padrão e gráficos nomeados do SPARQL
O Amazon Neptune associa cada triplo a um grafo nomeado. O gráfico padrão é definido como a união de todos os gráficos nomeados.
**Gráfico padrão para consultas**
Se você enviar uma consulta do SPARQL sem especificar explicitamente um gráfico por meio da palavra-chave `GRAPH` ou construções como `FROM NAMED`, o Neptune sempre considerará todos os trios em sua instância de banco de dados. Por exemplo, a seguinte consulta gera todos os triplos de um endpoint do SPARQL no Neptune:
`SELECT * WHERE { ?s ?p ?o }`
Trios que aparecem em mais de um gráfico são retornados somente uma vez.
Para obter informações sobre a especificação de gráfico padrão, consulte a seção [Dataset do RDF](https://www.w3.org/TR/sparql11-query/#rdfDataset) da especificação do SPARQL 1.1 Query Language.
**Especificar o gráfico nomeado para carregamentos, inserções ou atualizações**
Se você não especificar um grafo nomeado ao carregar, inserir ou atualizar triplos, o Neptune usará o grafo nomeado fallback definido pelo URI `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`.
Ao emitir uma solicitação `Load` do Neptune usando um formato baseado em triplos, é possível especificar o grafo nomeado a ser usado para todos os triplos com o parâmetro `parserConfiguration: namedGraphUri`. Para obter mais informações sobre a sintaxe do comando `Load`, consulte [Comando do carregador do Neptune](load-api-reference-load.md).
**Importante**
Se você não usar esse parâmetro e não especificar um gráfico nomeado, o URI de fallback será usado: `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`.
Esse gráfico nomeado de fallback também será usado se você carregar trios por meio de `SPARQL UPDATE` sem fornecer explicitamente um destino de gráfico nomeado.
Você pode usar o formato com base em quads, N-Quads, para especificar um gráfico nomeado para cada trio no banco de dados.
**nota**
O uso de N-Quads permite que você deixe o gráfico nomeado em branco. Nesse caso, `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph` é usado.
Você pode substituir o gráfico padrão nomeado para N-Quads usando a opção de configuração do analisador `namedGraphUri`.
## XPath Funções do construtor SPARQL suportadas pelo Neptune
O padrão SPARQL permite que os mecanismos SPARQL suportem um conjunto extensível de funções de XPath construtor. No momento, o Neptune é compatível com as seguintes funções de construtor, nas quais o prefixo `xsd` é definido como `http://www.w3.org/2001/XMLSchema#`:
+ `xsd:boolean`
+ `xsd:integer`
+ `xsd:double`
+ `xsd:float`
+ `xsd:decimal`
+ `xsd:long`
+ `xsd:unsignedLong`
## IRI de base padrão para consultas e atualizações
Como um cluster do Neptune tem vários endpoints diferentes, usar a URL de solicitação de uma consulta ou atualização como IRI base pode levar a resultados inesperados na resolução relativa. IRIs
A partir da [versão 1.2.1.0 do mecanismo](engine-releases-1.2.1.0.md), o Neptune usará `http://aws.amazon.com/neptune/default/` como IRI base se um IRI de base explícito não fizer parte da solicitação.
Na seguinte solicitação, o IRI de base faz parte da solicitação:
```
BASE
INSERT DATA { "n1" }
BASE
SELECT * { ?p ?o }
```
E o resultado seria:
```
?p ?o
http://example.org/default/id n1
```
No entanto, nesta solicitação, nenhum IRI de base está incluído:
```
INSERT DATA { "n1" }
SELECT * { ?p ?o }
```
Nesse caso, o resultado seria:
```
?p ?o
http://aws.amazon.com/neptune/default/id n1
```
## Valores xsd:dateTime no Neptune
Por motivos de desempenho, o Neptune sempre date/time armazena valores como Tempo Universal Coordenado (UTC). Isso torna as comparações diretas muito eficientes.
Também significa que se você inserir um valor `dateTime` que determine um fuso horário específico, o Neptune converterá o valor em UTC e descartará as informações de fuso horário. Depois, quando o valor `dateTime` for recuperado mais tarde, ele será expresso em UTC, não no fuso horário original, que não poderá mais ser determinado.
## Tratar valores de ponto flutuante especiais do Neptune
O Neptune trata os valores de ponto flutuante especiais no SPARQL da forma a seguir.
### Tratamento de NaN em SPARQL no Neptune
No Neptune, o SPARQL pode aceitar um valor de `NaN` em uma consulta. Não há distinção entre valores de `NaN` de sinalização e silenciosos. O Neptune trata todos os valores `NaN` como silenciosos.
Semanticamente, não é possível realizar uma comparação com um `NaN`, pois nada é maior que, menor que, nem igual a um `NaN`. Isso significa que um valor de `NaN` em um lado de uma comparação, teoricamente, nunca corresponde a *nada* do outro lado.
No entanto, a [especificação XSD](https://www.w3.org/TR/xmlschema-2/#double) trata dois valores `xsd:double` ou `xsd:float` `NaN` como iguais. O Neptune aplica isso ao filtro `IN`, para o operador igual em expressões de filtro e para a semântica de correspondência exata (com `NaN` na posição do objeto para um padrão triplo).
### Tratar valores infinitos do SPARQL no Neptune
No Neptune, o SPARQL pode aceitar um valor de `INF` ou `-INF` em uma consulta. O `INF` compara com outros valores numéricos superiores e o `-INF` compara com outros valores numéricos inferiores.
Dois valores INF com sinais correspondentes são comparados como iguais, independentemente do tipo (por exemplo, um `-INF` flutuante compara como igual a um `-INF` duplo).
Claro, não é possível realizar uma comparação com um `NaN`, pois nada é maior que, menor que, nem igual a um `NaN`.
### Tratar zero negativo do SPARQL no Neptune
O Neptune normaliza um valor de zero negativo para um zero sem sinal. Você pode usar valores de zero negativo em uma consulta, mas eles não são registrados dessa forma no banco de dados, pois são comparados como iguais a zeros sem sinal.
## Limitação de valores de comprimento arbitrário do Neptune
O Neptune limita o tamanho do armazenamento de valores inteiros XSD, de ponto flutuante e decimais no SPARQL a 64 bits. O uso de valores maiores gera um erro `InvalidNumericDataException`.
## O Neptune estende a comparação “igual a” no SPARQL
O padrão do SPARQL define uma lógica ternária para expressões de valor, nas quais uma expressão de valor pode ser avaliada como `true`, `false` ou `error`. A semântica padrão para a igualdade de termos, conforme definido na [especificação SPARQL 1.1](https://www.w3.org/TR/sparql11-query/#func-RDFterm-equal), que se aplica às comparações `=` e`!=` em condições de `FILTER`, produz um `error` ao comparar tipo de dados que não são explicitamente compatíveis na [tabela de operadores](https://www.w3.org/TR/sparql11-query/#OperatorMapping) da especificação.
Esse comportamento pode levar a resultados não intuitivos, conforme o exemplo a seguir.
Dados:
```
"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"^^)
}
```
Com a semântica SPARQL padrão usada pelo Neptune antes da versão 1.0.2.1, as duas consultas gerariam o resultado vazio. O motivo é que `?o = "127.0.0.2"^^` quando avaliado para `?o := "127.0.0.1"^^` gera um `error` em vez de `false`, porque não há regras de comparação explícitas especificadas para o tipo de dados personalizado ``. Como resultado, a versão negada na segunda consulta também gera um `error`. Em ambas as consultas, o `error` faz com que a solução candidata seja filtrada.
A partir da versão 1.0.2.1, o Neptune ampliou o operador de desigualdade do SPARQL de acordo com a especificação. Consulte a seção [SPARQL 1.1 section on operator extensibility](https://www.w3.org/TR/sparql11-query/#operatorExtensibility), que permite que os mecanismos definam regras adicionais sobre como comparar tipos de dados internos definidos pelos usuários e não comparáveis.
Ao usar essa opção, o Neptune trata uma comparação entre dois tipos de dados que não estão explicitamente definidos na tabela de mapeamento do operador como `true`, se os valores literais e os tipos de dados forem sintaticamente iguais, e falsos, caso não sejam. Um `error` não será produzido nesses casos.
Ao usar essas nova semânticas, a segunda consulta retornaria um `"127.0.0.1"^^` em vez de um resultado vazio.
## Manipulação de Out-of-Range literais em Neptune SPARQL
A semântica XSD define cada tipo numérico com o espaço de valor, exceto `integer` e `decimal`. Essas definições limitam todos os tipos a um intervalo de valores. Por exemplo, um intervalo de `xsd:byte` é de -128 a \$1127, inclusivo. Qualquer valor fora desse intervalo é considerado inválido.
Se você tentar atribuir um valor literal fora do espaço de valor de um tipo (por exemplo, se tentar definir an `xsd:byte` como um valor literal de 999), Netuno aceitará o valor como está, sem arredondá-lo ou truncá-lo. out-of-range Mas ele não continua como um valor numérico, porque o tipo determinado não pode representá-lo.
Ou seja, o Neptune aceita `"999"^^xsd:byte` mesmo estando fora do intervalo de valores `xsd:byte` definido. No entanto, após o valor continuar no banco de dados, ele poderá ser usado somente na semântica de correspondência exata, em uma posição do objeto de um padrão triplo. Nenhum filtro de intervalo pode ser executado nele porque out-of-range os literais não são tratados como valores numéricos.
A especificação SPARQL 1.1 define [operadores de intervalo](https://www.w3.org/TR/sparql11-query/#OperatorMapping) no formato `numeric`*-operator-*`numeric`, `string`*-operator-*`string`, `literal`*-operator-*`literal`, e assim em diante. O Neptune não pode executar um operador de comparação de intervalo como `invalid-literal`*-operator-*`numeric-value`.
# Conformidade com especificações do openCypher no Amazon Neptune
A versão do Amazon Neptune do openCypher geralmente é compatível com as cláusulas, a sintaxe, as expressões, as funções e os operadores definidos na especificação atual do openCypher, que é a [Cypher Query Language Reference versão 9](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf). As limitações e as diferenças na compatibilidade do Neptune com o openCypher estão descritas abaixo.
O Amazon Neptune também oferece suporte a vários recursos além do escopo da especificação do openCypher. Para mais detalhes, consulte [Extensões do openCypher no Amazon Neptune](access-graph-opencypher-extensions.md).
**nota**
A implementação atual do Neo4j do Cypher contém funcionalidades que não estão contidas na especificação do openCypher mencionada acima. Se você estiver migrando o código Cypher atual para o Neptune, consulte [Compatibilidade do Neptune com o Neo4j](migration-compatibility.md) e [Reformular consultas do Cypher para serem executadas no openCypher no Neptune](migration-opencypher-rewrites.md) para obter mais informações.
## Compatibilidade com cláusulas do openCypher no Neptune
O Neptune é compatível com as seguintes cláusulas, exceto conforme observado:
+ `MATCH`: compatível, exceto *`shortestPath()`* e *`allShortestPaths()`* no momento.
+ `OPTIONAL MATCH`
+ *`MANDATORY MATCH`*: no momento, **não** é compatível no Neptune. No entanto, o Neptune é compatível com [valores de ID personalizados](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids) em consultas `MATCH`.
+ `RETURN`: compatível, exceto quando usado com valores não estáticos para `SKIP` ou `LIMIT`. Por exemplo, o seguinte não funciona no momento:
```
MATCH (n)
RETURN n LIMIT toInteger(rand()) // Does NOT work!
```
+ `WITH`: compatível, exceto quando usado com valores não estáticos para `SKIP` ou `LIMIT`. Por exemplo, o seguinte não funciona no momento:
```
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`: o Neptune permite criar [valores de ID personalizados](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids) em consultas `CREATE`.
+ `DELETE`
+ `SET`
+ `REMOVE`
+ `MERGE`: o Neptune é compatível com [valores de ID personalizados](access-graph-opencypher-extensions.md#opencypher-compliance-custom-ids) em consultas `MERGE`.
+ *`CALL[YIELD...]`*: no momento, **não** é compatível no Neptune.
+ `UNION, UNION ALL`: consultas somente leitura são compatíveis, mas consultas de mutação **não** são aceitas no momento.
+ `USING`: `USING` é compatível com a versão [1.3.2.0](https://docs.aws.amazon.com//neptune/latest/userguide/engine-releases-1.3.2.0.html) do mecanismo. Consulte [Dicas de consultas](https://docs.aws.amazon.com//neptune/latest/userguide/opencypher-query-hints.html) para obter mais informações.
## Compatibilidade com operadores do openCypher no Neptune
O Neptune é compatível com os seguintes operadores, exceto conforme observado:
**Operadores gerais**
+ `DISTINCT`
+ O operador `.` para acessar as propriedades de um mapa literal aninhado.
**Operadores matemáticos**
+ O operador de adição `+`.
+ O operador de subtração `-`.
+ O operador de multiplicação `*`.
+ O operador de divisão `/`.
+ O operador de divisão de módulo `%`.
+ O operador de `^` exponenciação. *is NOT supported*
**Operadores de comparação**
+ O operador de adição `=`.
+ O operador de desigualdade `<>`.
+ O operador `<` menor que é compatível, exceto quando um dos argumentos é um caminho, uma lista ou um mapa.
+ O operador `>` maior que é compatível, exceto quando um dos argumentos é um caminho, uma lista ou um mapa.
+ O operador `<=` less-than-or-equal -to é suportado, exceto quando um dos argumentos é um caminho, uma lista ou um mapa.
+ O operador `>=` greater-than-or-equal -to é suportado, exceto quando um dos argumentos é um caminho, uma lista ou um mapa.
+ `IS NULL`
+ `IS NOT NULL`
+ `STARTS WITH` será compatível se os dados pesquisados forem uma string.
+ `ENDS WITH` será compatível se os dados pesquisados forem uma string.
+ `CONTAINS` será compatível se os dados pesquisados forem uma string.
**Operadores booleanos**
+ `AND`
+ `OR`
+ `XOR`
+ `NOT`
**Operadores de string**
+ O operador de concatenação `+`.
**Operadores List**
+ O operador de concatenação `+`.
+ `IN` (confere a presença de um item em uma lista).
## Compatibilidade com expressões do openCypher no Neptune
O Neptune é compatível com as seguintes expressões, exceto conforme observado:
+ `CASE`
+ No momento, a expressão `[]` **não** é compatível com o Neptune para acessar chaves de propriedade calculadas dinamicamente em um nó, um relacionamento ou um mapa. Por exemplo, o seguinte não funciona:
```
MATCH (n)
WITH [5, n, {key: 'value'}] AS list
RETURN list[1].name
```
## Compatibilidade com funções do openCypher no Neptune
O Neptune é compatível com as seguintes funções, exceto conforme observado:
**Funções de predicado**
+ `exists()`
**Funções escalares**
+ `coalesce()`
+ `endNode()`
+ `epochmillis()`
+ `head()`
+ `id()`
+ `last()`
+ `length()`
+ `randomUUID()`
+ `properties()`
+ `removeKeyFromMap`
+ `size()`: esse método sobrecarregado atualmente só funciona para expressões de padrões, listas e strings.
+ `startNode()`
+ `timestamp()`
+ `toBoolean()`
+ `toFloat()`
+ `toInteger()`
+ `type()`
**Agregar funções**
+ `avg()`
+ `collect()`
+ `count()`
+ `max()`
+ `min()`
+ `percentileDisc()`
+ `stDev()`
+ `percentileCont()`
+ `stDevP()`
+ `sum()`
**Listar as funções**
+ [`join()`](access-graph-opencypher-extensions.md#opencypher-compliance-join-function) (concatena strings em uma lista em uma única string).
+ `keys()`
+ `labels()`
+ `nodes()`
+ `range()`
+ `relationships()`
+ `reverse()`
+ `tail()`
**Funções matemáticas: numéricas.**
+ `abs()`
+ `ceil()`
+ `floor()`
+ `rand()`
+ `round()`
+ `sign()`
**Funções matemáticas: logarítmicas.**
+ `e()`
+ `exp()`
+ `log()`
+ `log10()`
+ `sqrt()`
**Funções matemáticas: trigonométricas.**
+ `acos()`
+ `asin()`
+ `atan()`
+ `atan2()`
+ `cos()`
+ `cot()`
+ `degrees()`
+ `pi()`
+ `radians()`
+ `sin()`
+ `tan()`
**Funções de string**
+ [`join()`](access-graph-opencypher-extensions.md#opencypher-compliance-join-function) (concatena strings em uma lista em uma única string).
+ `left()`
+ `lTrim()`
+ `replace()`
+ `reverse()`
+ `right()`
+ `rTrim()`
+ `split()`
+ `substring()`
+ `toLower()`
+ `toString()`
+ `toUpper()`
+ `trim()`
**Funções definidas pelo usuário**
*User-defined functions*atualmente **não** são compatíveis com o Neptune.
## Detalhes da implementação do openCypher específicos do Neptune
As seções a seguir descrevem as maneiras pelas quais a implementação do openCypher no Neptune pode diferir ou ir além da [especificação do openCypher](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf)
### Avaliações de caminho de comprimento variável (VLP) no Neptune
As avaliações de caminho de comprimento variável (`VLP`) descobrem caminhos entre os nós no grafo. O comprimento do caminho pode ser irrestrito em uma consulta. Para evitar ciclos, a [especificação do openCypher](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf) especifica que cada borda deve ser percorrida no máximo uma vez por solução.
Pois VLPs, a implementação do Neptune se desvia da especificação OpenCypher, pois só suporta valores constantes para filtros de igualdade de propriedades. Considere a seguinte consulta:
```
MATCH (x)-[:route*1..2 {dist:33, code:x.name}]->(y) return x,y
```
Como o valor do filtro de igualdade de propriedade `x.name` não é uma constante, essa consulta gera uma `UnsupportedOperationException` com a mensagem: `Property predicate over variable-length relationships with non-constant expression is not supported in this release.`
### Compatibilidade temporal na implementação do Neptune openCypher (banco de dados 1.3.1.0 do Neptune e versões anteriores)
No momento, o Neptune oferece compatibilidade limitada para funções temporais no openCypher. Ele é compatível com o tipo de dados `DateTime` para tipos temporais.
A função `datetime()` pode ser usada para obter a data e a hora UTC atuais da seguinte forma:
```
RETURN datetime() as res
```
Os valores de data e hora podem ser analisados a partir de strings em um formato `"`*date*`T`*time*`"` em que a *data* e a *hora* são expressas em uma das seguintes formas compatíveis:
**Formatos de data suportados**
+ `yyyy-MM-dd`
+ `yyyyMMdd`
+ `yyyy-MM`
+ `yyyy-DDD`
+ `yyyyDDD`
+ `yyyy`
**Formatos de hora compatíveis**
+ `HH:mm:ssZ`
+ `HHmmssZ`
+ `HH:mm:ssZ`
+ `HH:mmZ`
+ `HHmmZ`
+ `HHZ`
+ `HHmmss`
+ `HH:mm:ss`
+ `HH:mm`
+ `HHmm`
+ `HH`
Por exemplo:
```
RETURN datetime('2022-01-01T00:01') // or another example:
RETURN datetime('2022T0001')
```
Observe que todos os date/time valores no Neptune OpenCypher são armazenados e recuperados como valores UTC.
O openCypher no Neptune usa um relógio `statement`, o que significa que o mesmo instante no tempo é usado durante toda a duração de uma consulta. Uma consulta diferente na mesma transação pode usar um instante diferente no tempo.
O Neptune não é compatível com o uso de uma função em uma chamada para `datetime()`. Por exemplo, o seguinte não funcionará:
```
CREATE (:n {date:datetime(tostring(2021))}) // ---> NOT ALLOWED!
```
O Neptune é compatível com a função `epochmillis()` que converte uma `datetime` em `epochmillis`. Por exemplo:
```
MATCH (n) RETURN epochMillis(n.someDateTime)
1698972364782
```
No momento, o Neptune não é compatível com outras funções e operações em objetos `DateTime`, como adição e subtração.
### Compatibilidade temporal na implementação do Neptune openCypher (Neptune Analytics e banco de dados do Neptune 1.3.2.0 e superior)
A seguinte funcionalidade de data e hora OpenCypher se aplica ao Neptune Analytics. Como alternativa, você pode usar o parâmetro do modo de laboratório `DatetimeMillisecond=enabled` para habilitar a funcionalidade de data e hora a seguir na versão 1.3.2.0 e superior do mecanismo do Neptune. Para obter mais detalhes sobre como usar essa funcionalidade no modo de laboratório, consulte [Suporte estendido para data e hora](features-lab-mode.md#labmode-extended-datetime-support).
+ Compatibilidade para milissegundos. O literal de data e hora sempre será retornado com milissegundos, mesmo que os milissegundos sejam 0. (O comportamento anterior era truncar os milissegundos.)
```
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"
}
}
} ]
}
```
+ Compatibilidade para chamar a função datetime() em propriedades armazenadas ou resultados intermediários. Por exemplo, as consultas a seguir não eram possíveis antes desse recurso.
Datetime() em propriedades:
```
// 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 () em resultados intermediários:
```
// Parse datetime from parameter
UNWIND $list as myDate
RETURN datetime(myDate) as d
```
+ Agora também é possível salvar as propriedades de data e hora criadas nos casos mencionados acima.
Como salvar a data e hora da propriedade de string de uma propriedade para outra:
```
// 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)
```
Criar nós em lote a partir de um parâmetro com uma propriedade de data e 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 um subconjunto maior de formatos de ISO8601 data e hora. Consulte abaixo.
Formatos com suporte
O formato de um valor de data e hora é [Date]T[Time][Timezone], em que T é o separador. Se um fuso horário explícito não for fornecido, o UTC (Z) será considerado o padrão.
Fuso horário
Os formatos de fuso horário compatíveis são:
+ \$1/-HH:mm
+ \$1/-HHmm
+ \$1/-HH
A presença de um fuso horário em uma string de data e hora é opcional. Caso a diferença de fuso horário seja 0, Z pode ser usado em vez do postfix de fuso horário acima para indicar a hora em UTC. O intervalo compatível de um fuso horário é de -14:00 a \$114:00.
Data
Se nenhum fuso horário estiver presente ou se o fuso horário for UTC (Z), os formatos de data compatíveis serão os seguintes:
**nota**
DDD se refere a uma data ordinal, que representa um dia do ano de 001 a 365 (366 em anos bissextos). Por exemplo, 2024-002 representa 2 de janeiro de 2024.
+ `yyyy-MM-dd`
+ `yyyyMMdd`
+ `yyyy-MM`
+ `yyyyMM`
+ `yyyy-DDD`
+ `yyyyDDD`
+ `yyyy`
Se um fuso horário diferente de Z for escolhido, os formatos de data compatíveis serão limitados ao seguinte:
+ `yyyy-MM-dd`
+ `yyyy-DDD`
+ `yyyyDDD`
O intervalo compatível para datas é de 1400-01-01 até 9999-12-31.
Hora
Se nenhum fuso horário estiver presente ou se ele for UTC (Z), os formatos de hora compatíveis serão os seguintes:
+ `HH:mm:ss.SSS`
+ `HH:mm:ss`
+ `HHmmss.SSS`
+ `HHmmss`
+ `HH:mm`
+ `HHmm`
+ `HH`
Se um fuso horário diferente de Z for escolhido, os formatos de hora compatíveis serão limitados ao seguinte:
+ `HH:mm:ss`
+ `HH:mm:ss.SSS`
### Diferenças na semântica da linguagem openCypher do Neptune
Netuno representa o nó e o IDs relacionamento como cadeias de caracteres em vez de números inteiros. O ID é igual ao ID fornecido pelo carregador de dados. Se houver um namespace para a coluna, o namespace mais o ID. Consequentemente, a função `id` gera uma string em vez de um número inteiro.
O tipo de dados `INTEGER` é limitado a 64 bits. Ao converter valores de ponto flutuante ou string maiores em um número inteiro usando a função `TOINTEGER`, valores negativos são truncados em `LLONG_MIN` e valores positivos são truncados em `LLONG_MAX`.
Por exemplo:
```
RETURN TOINTEGER(2^100)
> 9223372036854775807
RETURN TOINTEGER(-1 * 2^100)
> -9223372036854775808
```
### Propriedades de vários valores
Embora o openCypher CREATE não crie propriedades de vários valores, elas podem existir em dados criados usando o Gremlin (banco de dados do Neptune) ou ao carregar dados (banco de dados do Neptune e Neptune Analytics). Se o openCypher do Neptune encontrar uma propriedade de vários valores, um dos valores será escolhido arbitrariamente, criando um resultado não determinístico.
### Tratar valores NaN
O tratamento do Neptune da comparação dos valores das propriedades `NaN` é indefinido. Confiar nessas comparações pode resultar em resultados inesperados ou não determinísticos.