Hi, I think he wants to query the customers by using a unique ID without having to map it as you propose.
Could I just ask something that is important to me ? As you say, the behavior in 1.7 is not as described, could you quickly explain how the multi-master architecture was working in 1.7 ? Thanks Stéphane Le lundi 15 décembre 2014 17:28:44 UTC+1, Lvc@ a écrit : > > Hi Mateusz. > If you have 3 nodes, you will have: > > - customer: #13:0 > - customer_node1: #14:0 > - customer_node2: #15:0 > > While with 1.7 you had. > > - customer: #13:0 > - customer: #13:1 > - customer: #13:2 > > Well, you could manage ID considering the node, so: > > - customer: #13:0 -> 0 > - customer_node1: #14:0 -> 1 > - customer_node2: #15:0 -> 2 > - customer: #13:1 -> 3 > - customer_node1: #14:1 -> 4 > - customer_node2: #15:1 -> 5 > - customer: #13:2 -> 6 > - customer_node1: #14:2 -> 7 > - customer_node2: #15:2 -> 8 > > WDYT? > > Lvc@ > > > On 15 December 2014 at 14:42, Mateusz Dymczyk <[email protected] > <javascript:>> wrote: >> >> Hey Luca, >> >> My usecase is very trivial: in my app cluster and class are synonyms as I >> always had only one cluster per class. Furthermore I allow my users to >> query the data by a long ID, rest style "URL/{classname}/{id}". The ID was >> basically the cluster position generated by Orient. Now I can't use that as >> I can have N records with the same cluster position for a given cluster >> type, where N is the number of nodes. With this I need to tell my users to >> use the whole {clusterId:clusterPos} string as an ID which is very user >> unfriendly and confusing... >> >> Somehow it's hard for me to believe no one else is using those IDs in >> such a way? That's pretty standard practice in ORMs etc. >> >> Mateusz >> >> On Monday, December 15, 2014 9:28:57 PM UTC+9, Lvc@ wrote: >>> >>> Hi guys, >>> The RID is always the same across all the nodes. But the used sequence >>> is per server. Playing with different clusters allows us to avoiding >>> conflicts. >>> >>> Unfortunately there is no way to force a clusterId on creation in >>> distributed mode if that clusterId is assigned to another server. This is >>> mandatory to avoid conflicts. >>> >>> @Mateusz, what's your use case? >>> >>> Lvc@ >>> >>> >>> On 15 December 2014 at 10:39, Stéphane Schild <[email protected]> >>> wrote: >>>> >>>> Thanks Lvc for your response ! >>>> >>>> To follow on Mateusz's question, is it really possible to have multiple >>>> records with the same id across distributed nodes ? >>>> Maybe is there some centralized sequence for cluster ids to avoid >>>> different classes to use the same cluster ids ? >>>> >>>> -- >>>> >>>> --- >>>> 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/d/optout. >>>> >>> -- >> >> --- >> 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/d/optout. >> > -- --- 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/d/optout.
