https://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705820.html
as you can see... it much depends on the platform. I would like to unify that (I'm doing it slooooowly, with certain plugins... but just when I have time, which is not very frequent :), and also it is not always possible)
>
> On 30 Aug 2013, at 16:54, Esteban Lorenzano <
[hidden email]> wrote:
>
>>
>> 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 :(
>
> 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 <
[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.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>