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