Oh I should have realized it was a collection. Thanks! Everything is 
working and super fast now.

On Friday, February 14, 2014 4:34:19 AM UTC-5, Lvc@ wrote:
>
> Hi,
> I think operator IN is the most appropriate:
>
> SELECT * FROM B where #1:0 IN in_points_to and prop = 'test'
>
> contains should be used with expressions against the collections item, 
> like:
>
> SELECT * FROM B where in_points_to contains ( latitude > 100 )
>
>
> Lvc@
>
>
>
> On 14 February 2014 07:26, Andrey Lomakin <[email protected]<javascript:>
> > wrote:
>
>> Hi,
>> = operator for single values like in Java but LINKBAG is bag (collection)
>> Query should be SELECT * FROM B where in_points_to contains #1:0 .
>>
>> About  composite index usage.
>> Just issue query
>>
>> SELECT * FROM B where in_points_to contains #1:0  and prop = 'test'
>>
>> and index will be reused automatically.
>>
>>
>>
>>
>> On Fri, Feb 14, 2014 at 1:35 AM, Mac Adada <[email protected]<javascript:>
>> > wrote:
>>
>>> Thanks, for the quick reply. I tried using LINKBAG and it seemed to work 
>>> perfectly, I verified everything was getting added to the index as it 
>>> should be. My trouble now comes from querying it. 
>>>
>>> Given class A  and class B connected by edge "points_to" (A -> B). I 
>>> created an index called testIdx of type LINKBAG on the "in_points_to" 
>>> property of B. I'm unclear on how to query the in_points_to property. doing 
>>> something like "SELECT * FROM B where in_points_to = #1:0" I get no 
>>> results. If however I do "SELECT * FROM index:testIdx" I see the index 
>>> entry is definitely there, with a key of #1:0.  I got around this by doing: 
>>> "SELECT * FROM B WHERE @RID IN (SELECT  rid from index:testIdx = #1:0)" and 
>>> this seems to work. 
>>>
>>> My first question is whether this is the right way to do it or not ?
>>>
>>> My second problem comes from using composite index with LINKBAG. If i 
>>> try to select a composite index as shown 
>>> https://github.com/orientechnologies/orientdb/wiki/Indexes , I get a 
>>> null pointer exception. Specifically doing something like SELECT FROM 
>>> index:testIdx where key = [#1:0, "test"] throws:
>>>
>>> Error: 
>>> com.orientechnologies.orient.enterprise.channel.binary.OResponseProcessingException:
>>>  
>>> Exception during response processing.
>>> Error: 
>>> com.orientechnologies.orient.core.exception.OCommandExecutionException: 
>>> Error on execution of command: sql.select * from index:testIdx where key = 
>>> [#1:0, "test"]
>>> Error: java.lang.NullPointerException
>>>
>>> Where as select * from index:testIdx shows that the index entry exists 
>>> and the key value is: OCompositeKey{keys=[#1:0, test]}
>>>
>>>  I'm not sure if i'm querying incorrectly or this is a bug. I'm running 
>>> 1.7-rc2 and my graph is from the develop branch from earlier today.
>>>
>>> Cheers,
>>> Mahmoud
>>>
>>>  
>>>
>>>
>>> On Thursday, February 13, 2014 5:37:55 AM UTC-5, Andrey Lomakin wrote:
>>>
>>>> Hi,
>>>> Yes it is possible , but you have to set type of field which is used 
>>>> for connection directly (you should set it to LINKBAG) here is example of 
>>>> non composite index https://github.com/orientechnologies/orientdb/
>>>> blob/develop/graphdb/src/test/java/com/orientechnologies/
>>>> orient/graph/blueprints/EdgeIndexingTest.java but creation of 
>>>> composite index is similar (fields for out edges use out_ prefix and 
>>>> fields 
>>>> for in edges use in_ prefix accordingly).
>>>>
>>>>
>>>>
>>>> On Wed, Feb 12, 2014 at 11:31 PM, Mac Adada <[email protected]> wrote:
>>>>
>>>>>
>>>>> Great, thanks for the help Andrey! 
>>>>>
>>>>> So it seems SQL is the way to go to get the most out of orientdb at 
>>>>> the moment. I have one further follow up question. Is it possible to 
>>>>> create 
>>>>> a composite key on incoming/outgoing edges, and then query it via SQL ? 
>>>>> ie 
>>>>> if I have Root{name:"root"} --> Test{id:1} and I would like to create an 
>>>>> index on something like (Test.id,Test.in.name).
>>>>>
>>>>> Cheers,
>>>>> Mahmoud
>>>>>
>>>>>
>>>>> On Wednesday, February 12, 2014 12:13:44 PM UTC-5, Andrey Lomakin 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>>
>>>>>>> When using the java api, the orient docs indicate that to use an 
>>>>>>> index with the getVerticies method, I should use 
>>>>>>> getVerticies(Class.Property, value) ie 
>>>>>>> getVerticies("TestClass.testId",123) 
>>>>>>> . However does the same apply when using gremlin ?  If i had something 
>>>>>>> like 
>>>>>>> g. ... .out("link_to_test").has("testId",123) would gremlin use the 
>>>>>>> testId index ? Because has("Test.testId",123) does not seem to work.
>>>>>>
>>>>>>
>>>>>> Gremlin needs vertex centric index for such kind of queries it is in 
>>>>>> our roadmap but is not implemented yet.
>>>>>>
>>>>>>> Am I right in assuming something like 
>>>>>>> pipe.start(root).out("link_to_test").has("testId",123) 
>>>>>>> can't be represented using the VertexQuery api ? Something like 
>>>>>>> root.query().labels("link_to_test").vertices() would return a list 
>>>>>>> of vertices and I would have to filter them manually by the testId 
>>>>>>> property 
>>>>>>> ?
>>>>>>
>>>>>>  Yes you are right.
>>>>>>
>>>>>>> Are there any performance advantages/disadvantages to using the 
>>>>>>> VertexQuery or gremlin api as opposed to the SQL api ?
>>>>>>
>>>>>> Usually SQL queries are faster because they use database internal 
>>>>>> features.
>>>>>>
>>>>>>> If I create a compound index, is there anyway to query over that 
>>>>>>> compound index using the gremlin api ?
>>>>>>
>>>>>> You should use SQL in such case, gremlin does not have such kind of 
>>>>>> index in it's model.
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 12, 2014 at 2:19 AM, Mac Adada <[email protected]> wrote:
>>>>>>
>>>>>>> Hey all,
>>>>>>>
>>>>>>> New to graph DBs and to Orient in particular. I have a few questions 
>>>>>>> I can't seem to find the answer to, and was wondering if anyone could 
>>>>>>> help.
>>>>>>>
>>>>>>>
>>>>>>>    1. When using the java api, the orient docs indicate that to use 
>>>>>>>    an index with the getVerticies method, I should use 
>>>>>>>    getVerticies(Class.Property, value) ie getVerticies("TestClass.
>>>>>>>    testId",123) . However does the same apply when using gremlin ? 
>>>>>>>     If i had something like g. ... 
>>>>>>> .out("link_to_test").has("testId",123) 
>>>>>>>    would gremlin use the testId index ? Because has("Test.testId",123) 
>>>>>>>    does not seem to work. 
>>>>>>>    2. Am I right in assuming something like 
>>>>>>>    pipe.start(root).out("link_to_test").has("testId",123) can't be 
>>>>>>>    represented using the VertexQuery api ? Something like 
>>>>>>>    root.query().labels("link_to_test").vertices() would return a 
>>>>>>>    list of vertices and I would have to filter them manually by the 
>>>>>>> testId 
>>>>>>>    property ? 
>>>>>>>    3. Are there any performance advantages/disadvantages to using 
>>>>>>>    the VertexQuery or gremlin api as opposed to the SQL api ?
>>>>>>>    4. If I create a compound index, is there anyway to query over 
>>>>>>>    that compound index using the gremlin api ? 
>>>>>>>
>>>>>>> I apologize if some of these questions have already been asked and 
>>>>>>> answered. Thanks for the help!
>>>>>>> Mahmoud
>>>>>>>
>>>>>>> -- 
>>>>>>>  
>>>>>>> --- 
>>>>>>> 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 [email protected].
>>>>>>>
>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Best regards,
>>>>>> Andrey Lomakin.
>>>>>>
>>>>>> Orient Technologies
>>>>>> the Company behind OrientDB
>>>>>>
>>>>>>   -- 
>>>>>  
>>>>> --- 
>>>>> 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 [email protected].
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Best regards,
>>>> Andrey Lomakin.
>>>>
>>>> Orient Technologies
>>>> the Company behind OrientDB
>>>>
>>>>   -- 
>>>  
>>> --- 
>>> 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 [email protected] <javascript:>.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
>>
>> -- 
>> Best regards,
>> Andrey Lomakin.
>>
>> Orient Technologies
>> the Company behind OrientDB
>>
>>  -- 
>>  
>> --- 
>> 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 [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 

--- 
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to