>
> On Aug 30, 2013, at 4:49 PM, Sven Van Caekenberghe <[hidden email]> wrote:
>
>>
>> On 30 Aug 2013, at 16:35, Esteban Lorenzano <[hidden email]> wrote:
>>
>>>
>>> On Aug 29, 2013, at 5:08 PM, Sven Van Caekenberghe <[hidden email]> wrote:
>>>
>>>>
>>>> On 29 Aug 2013, at 16:51, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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.
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>