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.
