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

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