[orientdb] Counting Edges Between Vertices

[John J. Szucs]

In the spirit of giving back to the community, I am sharing a problem and 
solution that I just discovered in working with OrientDB.

For my application, I need to be able to *very* quickly determine how many 
(zero or more, often, but not always zero or one) edges with a given label 
and direction exist between two vertices.

The pure Java solution is OrientVertex.getEdges(otherVertex, direction, 
labels ...) but it returns an OMultiCollectionIterable of *all* the edges 
adjacent to the first vertex that match the label and direction criteria. 
Then it post-filters them for adjacency to the second vertex. This can be 
very slow if the first vertex has many edges that match the label and 
direction criteria.

As an alternative, if you only need the count (like I do) and need it to be 
as fast as possible, consider a SQL query like the following:

SELECT IN('myLabel')[@rid=:vertex2].SIZE() FROM :vertex1

Replace the IN function with BOTH or OUT as needed. The fragment above uses 
parameterized SQL, with the :vertex1 and :vertex2 parameters specifying the 
vertices of interest.

OrientDB team: Should I add to this to the "query cookbook" in the 
documentation?

-- John

-- 

--- 
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 orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [orientdb] Doubt and failure about indexes

[André Toscano]

Hi Roberto and everyone.
Thank you for your answer.
The redefinition showed was wrong, we don't do that.
We remove all the lucene full text indexes from subclasses. Instead, we add 
a property string to put the @class.asString() in the objects and we add it 
in the lucene index do enable class search.
Solved all the problems except one behavior that is related to drop a 
class. 
We have a lucene index in a class and we extend the class in a subclass, if 
we drop the subclass the rebuild index * is called.
About the "allowLeadingWildcard", but guys here love asterisk, so we will 
keep it enable from now.
Best regards.
André


Em sexta-feira, 17 de fevereiro de 2017 12:21:37 UTC-2, Roberto Franchini 
escreveu:
>
>
>
> On Fri, 17 Feb 2017 at 14:36 André Toscano  > wrote:
>
>> Hi Luca and everyone
>> I will describe our use case and make a question about Lucene indexes.
>> We developed a hybrid schema in Orientdb defining classes storing 
>> documents (nested) and since we love Lucene indexes to enable their use we 
>> always dump a document into a string property.
>> To establish the ER we use the direct approach to define Vertexes as 
>> Entities and Edges as Relationships.
>> So the basic schema can be describe in oSQL:
>>
>> create class Entities extends V
>> create property Entitites.sdoc STRING
>> create property Entities.location EMBEDDED OPoint
>> create create index Entity.location ON Entity(location) SPATIAL ENGINE 
>> LUCENE
>> create index Entity.ssdoc on Entity(sdoc) FULLTEXT ENGINE LUCENE METADATA 
>> {"allowLeadingWildcard": true}
>>
>
> fixed from typos:
>
> create class Entities extends V
> create property Entities.sdoc STRING
> create property Entities.location EMBEDDED OPoint
> create index Entities.location ON Entities(location) SPATIAL ENGINE LUCENE
> create index Entities.ssdoc on Entities(sdoc) FULLTEXT ENGINE LUCENE 
> METADATA {"allowLeadingWildcard": true}
>
>  [cut]
>  
>
>> and
>>
>> Create Vertex Companies content 
>> {'key':{'key2':'value1','keylist':[1,2,3,4]},'key3': 
>> 10,'key':[{'key4':'values'}]} RETURN @rid
>> update <@rid above1> set location = [-39.0,18]
>> update <@rid above1> set sdoc = 
>> "{'key':{'key2':'value1','keylist':[1,2,3,4]},'key3': 
>> 10,'key':[{'key4':'values'}]}"
>>
>>
> Ok, even this commands are wrong, location is an OPoint. I guess it's il 
> almost psedo-code 
>
>
>  
>
>> Suppose that we have a contract between the two companies, so we would 
>> create:
>>
>> create class Contracts extends Relationships
>> create property Relationships.sdoc STRING
>> create index Relationships.ssdoc on Relationships(sdoc) FULLTEXT ENGINE 
>> LUCENE METADATA {"allowLeadingWildcard": true}
>>
>>
> Why are you re-defining props and indexes at the sub-class level? Is it 
> only a typo ora re you doing it for real?
>  
> [cut]
>
>>
>> Now, the problem:
>>
>> We keeping using the database like presented above and sometimes, when we 
>> create and drop classes, the lucene indexes stops to work and we need to 
>> execute: 
>>
>> rebuild index *
>>
>
> My sugestio is to create lucene indexes only one time: on the superclass 
> OR on the subclass
> Can you try defining  the index only in one place and report if it break 
> again?
>
> Moreove, my suggestion is to AVOID "allowLeadingWildcard", it will slow 
> down your search and it is a "wrong" way to work with lucene :) (but maybe 
> you need to work this way)
>
>
> -- 
> Best regards,
>  
> Roberto Franchini
>
> OrientDB LTD  -  http://orientdb.com
>

-- 

--- 
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 orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [orientdb] what is difference b/w link and egde

[Luigi Dell'Aquila]

Hi,

A link is just a physical pointer, eg.

Record 1: {@rid: #12:0, name:"John" }
Record 2: {@rid: #12:1, name:"Frank", friendOf:#12:0 }

the friendOf attribute here is a link. Given Record 2, you can easily find
Record 1 following the link, but if you only know Record 1 you have no
information about connected nodes.

An edge is a bit more complex structure, it's actually a document:

Vertex 1: {@rid: #12:0, name:"John", out_friendOf:#13:0 }

Edge: {@rid: #13:0, out:#12:0, in:#12:1, since: 1/3/2015 }

Vertex 2: {@rid: #12:1, name:"Frank", in_friendOf:#13:0 }

As you can see, the underlying structure relies on links (out/in_friendOf
on the vertices and out/in on the edge), but
- the edge is a document, so it can have properties ("since" in this case)
- you have links on both sides, so you can efficiently traverse the edge in
both directions

Thanks

Luigi


2017-03-15 13:12 GMT+01:00 thulaseeswara reddy gajjala <
tech.esw...@gmail.com>:

> hi
> when we use edges and when we used links in real time scenarios.  Is there
> any difference from both
> thanks
>
> --
>
> ---
> 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 orient-database+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
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 orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] what is difference b/w link and egde

[thulaseeswara reddy gajjala]

hi 
when we use edges and when we used links in real time scenarios.  Is there 
any difference from both 
thanks

-- 

--- 
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 orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.