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 -- --- 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.
