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