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]<javascript:> > > 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] >> <javascript:>>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] <javascript:>. >>> 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.
