Hi,
Which version of OrientDB are you using? We fixed a similar problem a few
hotfix releases ago
Thanks
Luigi
2016-04-18 18:12 GMT+02:00 K Major :
> Hello,
>
> I have identified a strange behavior when using OSQL inside Java. Maybe
> I'm doing something wrong ...
>
>
Hello,
I have identified a strange behavior when using OSQL inside Java. Maybe I'm
doing something wrong ...
*Problem : **The operators >,<, >=, <= don't seem not to work when used in
OSQL embedded in Java *
*Following graph*
Nodes:
v(Person)[#11:0]:name=1, age=71,
v(Person)[#11:1]:name=2,
Grazie mille funziona. Ho trovato un "bug" (non so se lo sia) nel database
che sto usando, ovvero c'è una sorta di arco fantasma. Mi spiego meglio,
quando stampo tutti gli archi del database, questo arco non compare nella
lista ma sia negli archi in di un certo articolo sia nel conteggio nelle
Because activities is defined as:
"activities": [{"day": 27, "type": "excursion", data: "Buenos
Aires"}, {"day": 28, "type": "picnic", data: "Delta Tigre"}, {"day": 30,
"type": "nightclub", data: "Oh lalala"}, ]
On Thursday, April 14, 2016 at 9:15:50 PM UTC-7, scott molinari wrote:
>
>
Hi pabloa,
what type is 'activities' (embedded, embeddedlist, embeddedmap,...) ?
Thanks
Luca
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Hi,
In my latest tests before migrating from 1.7.8 to version 2.1.8. With
earlier version, an kind of index index is required on Links, but since
2.1+ it will be much slower if an index is created on a LINK property. I
guess LINK will now use an kind of internal identifier indexing.
However,
Hi,
if you insert an index on the property Account ( NOTUNIQUE_HASH_INDEX) you
should improve the performances.
Kind regards,
Alessandro
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To unsubscribe from this group and stop receiving
Il 18/04/2016 10:25, Roberto Franchini ha scritto:
> Now, ETL. If you configure ET to store on a given cluster, all the
> document loaded will be store in that cluster.
> So, you can load different data's partition on different clusters of
> the same class.
> Suppose to have 12 CSVs, one for each
Grazie, ho provato a trovare l'articolo maggiormente citato con la seguente
query:
Select Titolo, in().size("cites") as numerocitazioni from Articolo where
numerocitazioni >=( SELECT max(in().size("cites")) FROM Articolo)
Ma non da niente come risultato. Come risolvere?
Il giorno lunedì 11
Il 18/04/2016 10:25, Roberto Franchini ha scritto:
> Now, ETL. If you configure ET to store on a given cluster, all the
> document loaded will be store in that cluster.
> So, you can load different data's partition on different clusters of
> the same class.
> Suppose to have 12 CSVs, one for each
L'alias "numerocitazioni" non puoi usarlo direttamente, ma riesci a usarlo
nella query esterna a quello in cui l'hai creato.
Poi nel where devi usare 'in' e non >= perchè il risultato del max credo
sia visto come una lista.
Giusto per correttezza il nome dell'arco "cites" è piu corretto
testdata: https://support.spatialkey.com/spatialkey-sample-csv-data/
test.json file :
{
"config":{
"log": "debug"
},
"begin": [
],
"source" : {
"file": { "path": "./test.csv", "lock" : false }
},
"extractor" : {
"row": {}
},
"transformers" :
Hi,
try this json:
{
"source": { "file": { "path":
"/home/ivan/Scrivania/etl/comm18-04/data.csv" } },
"extractor": { "csv": {} },
"loader": {
"orientdb": {
"dbURL":
"plocal:/home/ivan/OrientDB/db_installati/enterprise/orientdb-enterprise-2.1.15/databases/comm1804",
Does it work?
It is excursion and picnic you are looking to filter on, so I am not sure
why you added .data.
Scott
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an
Ok. I see from the other thread, you say it works and I understand what you
are wanting to do.
I am also not certain why the filtering is happening in the SELECT
identifiers.
Scott
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To
Hello,
I have a class *User* with this structure (same structure than my question
of the other day).
{
"userId":23232,
"activities": [{"day": 27, "type": "excursion", data: "Buenos Aires"},
{"day": 28, "type": "picnic", data: "Delta Tigre"}, {"day": 30, "type":
"nightclub", data: "Oh
On Sat, Apr 16, 2016 at 9:24 PM, Fabio Rinnone wrote:
> Il 15/04/2016 16:10, Roberto Franchini ha scritto:
>> On Fri, Apr 15, 2016 at 12:29 PM, Fabio Rinnone
>> wrote:
[cut]
>
> Thank you, now it creates cluster, but my question is little
Hi,
My application is running on OrientDB v2.1.8, the Contact table consists of
102 rows.
I have tried many way to write a Count query but the performance is a pain
at this point.
SELECT count(*) FROM Contact WHERE (Account = #20:1) AND (EntityInfo.State
= 0)
=> Query executed in 25.481
18 matches
Mail list logo