Posted by
Sven Van Caekenberghe-2 on
Aug 31, 2013; 1:30pm
URL: https://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705931.html
On 31 Aug 2013, at 13:47, Stéphane Ducasse <
[hidden email]> 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 <
[hidden email]> 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.
>