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 <macad...@gmail.com> 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 <maca...@gmail.com> 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 <maca...@gmail.com> 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 orient-databa...@googlegroups.com. >>>>> >>>>> 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 orient-databa...@googlegroups.com. >>> 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 orient-database+unsubscr...@googlegroups.com. > 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 orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
