On 30 Aug 2013, at 16:54, Esteban Lorenzano <esteba...@gmail.com> wrote:
> > On Aug 30, 2013, at 4:49 PM, Sven Van Caekenberghe <s...@beta9.be> wrote: > >> >> On 30 Aug 2013, at 16:35, Esteban Lorenzano <esteba...@gmail.com> wrote: >> >>> >>> On Aug 29, 2013, at 5:08 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote: >>> >>>> >>>> On 29 Aug 2013, at 16:51, Esteban Lorenzano <esteba...@gmail.com> wrote: >>>> >>>>> hi >>>>> >>>>> well... I've never been happy on using the UUID generator for my keys, >>>>> but is the fastest option I found. >>>>> There are, of course, alternatives: >>>>> >>>>> 1) Using your own number generator (sequential, or whatever). Problem >>>>> with that is that is image based, then you need a persistence strategy... >>>>> then you are slow. >>>>> 2) then you can use your own procedure in mongo... with same problem than >>>>> (1) >>>>> 3) you could use timestamp. but TimeStamps are slow :( >>>>> >>>>> anyway... I open to ideas :) >>>>> >>>>> in the mean time, you can check if your UUID generator is using the >>>>> primitive or not. In you are not, you have more possibilities of having a >>>>> collision. >>>> >>>> Yes, the Smalltalk code (type 4 UUID) is just a random number that is >>>> computed in a complex way. >>>> >>>> What does the primitive actually do ? Is it different ? >>> >>> the primitive uses the clock ticks to produce an UUID... you shouldn't have >>> repeated numbers that way... but well, it depends on the platform >>> implementation also. >> >> I don't like plugins because it is some much harder for everyone to look at >> the implementation, while everybody thinks some magic happens there, and >> often the truth is quite disappointing. >> >> Maybe the resolution of #primUTCMicrosecondsClock is not high enough ? > > I tried... not enough :( I understand: the clock is not fast enough for the request rate. But then what is there against some counter as part of a UUID ? Sorry for the discussion, I find it an interesting subject. I'll have to read a bit about UUIDs. Can anyone point to the plugin implementation code ? >>>>> Esteban >>>>> >>>>> On Aug 29, 2013, at 11:27 AM, Sabine Knöfel <sabine.knoe...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi Esteban, All, >>>>>> >>>>>> I was proceeding to seach for the reason of the problem I described >>>>>> yesterday. >>>>>> >>>>>> I added some debugging code into VOMongoSerializer>>ensurePersisted: and >>>>>> the >>>>>> problem I described, did NOT occur. >>>>>> >>>>>> That made the whole process slower...and I had an idea.... >>>>>> >>>>>> I was looking into >>UUIDGenerator default makeSeed. >>>>>> Then I tried the following code: >>>>>> >>>>>> |theOld theNew| >>>>>> >>>>>> 100000000 timesRepeat: [ >>>>>> theNew := UUIDGenerator default makeSeed. >>>>>> theNew = theOld ifTrue: [self halt]. >>>>>> theOld := theNew] >>>>>> >>>>>> The debugger came up! Doesn't that mean that, if the code is run very >>>>>> fast, >>>>>> there are double OIDs generated?! >>>>>> >>>>>> In my case, the objects for country and currency are very lightweight and >>>>>> so, they are created very fast. Also, the error occured much more often >>>>>> within my fast production EC2 instance as at my (old and slow) >>>>>> development >>>>>> pc. >>>>>> >>>>>> Important: I work with windows and so >>makeUnixSeed returns nil... :-) >>>>>> >>>>>> What is your opinion about that? >>>>>> >>>>>> Sabine >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705603.html >>>>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >