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