On 31 Aug 2013, at 13:47, Stéphane Ducasse <stephane.duca...@inria.fr> wrote:
> Sabine > what we could do is to propose a "subclass of UUID" and to group several UUID > generators. > Like that with a couple of classes, we could get a better eco system where > people can pick the one they want. > > stef I just made my own, called NeoUUIDGenerator, http://www.smalltalkhub.com/#!/~SvenVanCaekenberghe/Neo/packages/Neo-UUID @Sabine IMHO what I think a local counter does not, is give you uniques over different machines, images, instances - that is why there is also the concept of node identification. In my implementation I combine the millisecond clock, a small random number, a counter and a node id. The node id is based on several elements, it should be different when running multiple images. This is a hack, not something that I can prove mathematically. But it can't be worse than pure random. I think the speed is also acceptable: | generator | generator := NeoUUIDGenerator new. [ generator next ] bench. '408,000 per second.' | generator | generator := UUIDGenerator new. [ generator generateBytes: UUID nilUUID forVersion: 4 ] bench. '13,300 per second.' Sven > On Aug 31, 2013, at 11:49 AM, Sabine Knöfel <sabine.knoe...@gmail.com> wrote: > >> Hi Esteban, >> >> yes, Mongo is not very communicative ;-) >> >> I replaced OID>>nextOID with my own RKAOIDGenerator >> >> nextOID >> ^self value: (RKAOIDGenerator getNextOID) >> >> instead of >> >> nextOID >> ^self value: (UUIDGenerator default makeSeed) >> >> >> RKAOIDGenerator uses Time>>primMillisecondClock at startup and adds +1 each >> time I getNextOID as you suggested. >> >> This works fine. It seems to be much much much faster than the existing >> solution. >> >> [4000 timesRepeat: [UUIDGenerator default makeSeed]] timeToRun ==>> 5817 >> [4000 timesRepeat: [RKAOIDGenerator getNextOID]] timeToRun ==> 1 (!!) >> >> Perhaps a solution like this would be a better solution for all because it >> is faster and guarantees unique IDs? >> >> Sabine >> >> >> >> >> >> On Fri, Aug 30, 2013 at 5:58 PM, EstebanLM [via Smalltalk] <[hidden email]> >> wrote: >> Hi, >> >> One idea (not sure if it will work) >> >> You can take >> >> Time primUTCMicrosecondsClock >> >> when system start, then increase it sequentially. >> most probably that will ensure uniqueness while providing fast ids. >> >> but of course, that depends, you need to check in your system. >> >> I'm thinking on provide different ID generators for Voyage, and let people >> plug what is more convenient for them. >> >> (all of this happens because, unlike other db drivers, mongo does not answer >> the inserted id :( ) >> >> Esteban >> >> On Aug 30, 2013, at 5:41 PM, Sabine Knöfel <[hidden email]> wrote: >> >> > So, I will wait and till then, use the solution of Jan. >> > Thank you, Jan for the file in. >> > Sabine >> > >> > >> > >> > -- >> > View this message in context: >> > http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705821.html >> >> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> > >> >> >> >> >> If you reply to this email, your message will be added to the discussion >> below: >> http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705827.html >> To unsubscribe from voyage/mongo randomly wrong OIDs, click here. >> NAML >> >> >> View this message in context: Re: voyage/mongo randomly wrong OIDs >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >
