Hi, Only in case if you will have unique index, it is done btw there is example of such index usage https://github.com/orientechnologies/orientdb/blob/develop/graphdb/src/test/java/com/orientechnologies/orient/graph/blueprints/EdgeIndexingTest.java
On Sun, Feb 16, 2014 at 5:39 PM, Giraldo Rosales <[email protected]> wrote: > Once this item is closed, duplicate edges will not be able to be created, > correct? So if I run the following, twice: > CREATE EDGE isFollowing FROM #9:5 TO #9:4 > > It should only create one edge and not two of the same? > > > > > > On Wednesday, January 15, 2014 10:15:51 AM UTC-5, Andrey Lomakin wrote: > >> Just to track issue status https://github.com/orientechnologies/orientdb/ >> issues/1966 >> >> >> On Wed, Jan 15, 2014 at 5:14 PM, Andrey Lomakin <[email protected]>wrote: >> >>> Hi, >>> >>> Sure we will reproduce given issue to verify it. >>> But it will take a bit time. >>> >>> I will create bug report for 1.7 it is very inconvenient to have >>> mystical or buggy behavior for popular use cases. >>> >>> And thank you for usage of OrientDB. >>> We try to fix this issue in short term. >>> >>> >>> On Wed, Jan 15, 2014 at 3:52 PM, SHak <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> Thanks for the explanation. I don't see why the edge could be dirty, >>>> the record is quite old, that's why I'm concerned. I understand that you >>>> made the change but that must affect performance. I hope that you would >>>> reconsider and follow my very easy steps in reproducing the issue and >>>> discover the true cause of the problem. Maybe we can avoid transaction, >>>> maybe not. but would be nice to know why we are incurring this extra >>>> overhead if we have too and if we don't, wouldn't that be nice for all of >>>> us :) >>>> >>>> Even if you decide to continue with the transaction, it would be good >>>> to know what the issue is and know that the fix/workaround is for the right >>>> reasons. >>>> >>>> I know I'm new to the group and I don't mean any disrespect. I want >>>> you guys to beat Neo4j and I want to help by making OrientDB the choice at >>>> my company and the choice for everyone else out there. >>>> >>>> Best Regards >>>> >>>> On Wednesday, January 15, 2014 2:31:51 PM UTC+2, Lvc@ wrote: >>>> >>>>> Hi Shak, >>>>> the problem is that without a transaction the creation of edge could >>>>> be dirty. OrientDB tries to fix dirty reference, so maybe that's the >>>>> reason >>>>> why the next time the exception is raised. I've changed the default >>>>> behavior of all SQL commands against Graphs to be always transactional. >>>>> >>>>> It's in "develop" branch (2.0-SNAPSHOT). >>>>> >>>>> Lvc@ >>>>> >>>>> >>>>> >>>>> On 15 January 2014 12:09, SHak <[email protected]> wrote: >>>>> >>>>>> I wasn't in the previous discussions. I'm new to OrientDB. started >>>>>> this week :) This is strange to me that the answer would be a >>>>>> transaction. >>>>>> Forgive me since my transaction knowledge is based on RDBMS. >>>>>> >>>>>> A transaction is to do a unit of work in one shot. in this case, the >>>>>> record for Luca was written minutes/hours ago, the record for Language >>>>>> was >>>>>> written also minutes/hours ago. The edge was also written minutes/hours >>>>>> ago, so it's stored, indexed, etc. >>>>>> >>>>>> so there is no reason for the database not to find either of these >>>>>> records or the index. There is only 1 write operation here and 2 reads >>>>>> that should be consistent. >>>>>> >>>>>> IMO. It seems to me that if I need to put a transaction around every >>>>>> statement then I'm going to affect performance and all claims for >>>>>> OrientDB >>>>>> performance is out the door. Something here is fishy and I would think >>>>>> this is a bug and setting a transaction is more like a hack in this case. >>>>>> I cannot see a reason why a written record would fail on first attempt >>>>>> with exception of duplicate and then work the 2nd time. (Obviously I >>>>>> know >>>>>> nothing about OrientDB internals) But sounds to me like either a cache >>>>>> problem (hopefully) or a much more serious and bigger problem with the >>>>>> indexes. >>>>>> >>>>>> Can someone explain how this statement is processed internally and >>>>>> why a transaction is needed or if you could point to existing >>>>>> discussion/wiki/documentation? >>>>>> >>>>>> >>>>>> On Wednesday, January 15, 2014 12:03:49 PM UTC+2, Andrey Lomakin >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> That is because you do not run in tx environment, we discussed this >>>>>>> before, if you want to perform your operations as single atomic unit you >>>>>>> should make queries like: >>>>>>> *transactional create edge speaks from (select from User where name >>>>>>> = 'Luca') to (select from Language where name = 'En-uk')* >>>>>>> >>>>>>> in such case all changes will be atomic. >>>>>>> >>>>>>> I think it is better to run graph commands in tx mode automatically >>>>>>> to avoid such questions. >>>>>>> Guys WDYT ? >>>>>>> >>>>>>> >>>>>>> On Wed, Jan 15, 2014 at 11:50 AM, Luca Garulli <[email protected]>wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> the best way to create a bug is the issue tracker, but this is the >>>>>>>> best place to ask information and discuss about OrientDB. So the best >>>>>>>> is: >>>>>>>> 1) look at issue tracker if the error has already been fixed. Or >>>>>>>> try last snapshot ("develop" branch of github) >>>>>>>> 2) if the problem persists even in latest version, open a new issue >>>>>>>> to be tracked >>>>>>>> >>>>>>>> Lvc@ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 15 January 2014 10:07, SHak <[email protected]> wrote: >>>>>>>> >>>>>>>>> Is this the appropriate place to create bugs? This is obviously a >>>>>>>>> serious one as we cannot trust a database once it allows duplicate >>>>>>>>> edges on >>>>>>>>> unique index. I don't want it lost among group discussions or are the >>>>>>>>> developers keeping an eye on bugs reported here. please advice to >>>>>>>>> better >>>>>>>>> do my part properly. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tuesday, January 14, 2014 4:33:05 PM UTC+2, SHak wrote: >>>>>>>>>> >>>>>>>>>> Using version 1.6.3. I am able to create duplicate edge on every >>>>>>>>>> second attempt to create edge. I have Vertex for User and for >>>>>>>>>> Language and >>>>>>>>>> an Edge speaks between the User and Language. >>>>>>>>>> >>>>>>>>>> On first attempt to create an edge, it succeeds. *create edge >>>>>>>>>> speaks from (select from User where name = 'Luca') to (select from >>>>>>>>>> Language >>>>>>>>>> where name = 'En-uk');* >>>>>>>>>> 2nd attempt to create the same edge, it gives me a warning that >>>>>>>>>> unique index exists and refuses to create the edge. >>>>>>>>>> 3rd attempt works. >>>>>>>>>> 4th attempt fails and so on. >>>>>>>>>> >>>>>>>>>> It seems that once an exception is thrown the next request will >>>>>>>>>> create a duplicate. is the way I'm creating my index is wrong? >>>>>>>>>> >>>>>>>>>> *Data Setup:* >>>>>>>>>> ========================================================== >>>>>>>>>> #create classes/vectors >>>>>>>>>> create class User extends V; >>>>>>>>>> create class Language extends V; >>>>>>>>>> >>>>>>>>>> #create edges >>>>>>>>>> create class speaks extends E; >>>>>>>>>> >>>>>>>>>> #create User Data >>>>>>>>>> create vertex User set name = 'Luca'; >>>>>>>>>> create vertex User set name = 'Joe'; >>>>>>>>>> >>>>>>>>>> #create Language Data >>>>>>>>>> create vertex Language set name = 'En-uk'; >>>>>>>>>> create vertex Language set name = 'En-us'; >>>>>>>>>> create vertex Language set name = 'Fr-fr'; >>>>>>>>>> create vertex Language set name = 'Ru-ru'; >>>>>>>>>> create vertex Language set name = 'Ar-sy'; >>>>>>>>>> >>>>>>>>>> #index >>>>>>>>>> create property speaks.out LINK; >>>>>>>>>> create property speaks.in LINK; >>>>>>>>>> CREATE INDEX unique_speaks ON speaks (in, out) UNIQUE; >>>>>>>>>> >>>>>>>>>> =============================================== >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> >>>>>>>>> --- >>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> --- >>>>>>>> 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. >>>>>> >>>>> >>>>> -- >>>> >>>> --- >>>> 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 >>> >>> >> >> >> -- >> 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]. For more options, visit https://groups.google.com/groups/opt_out.
