On 31 Aug 2013, at 13:47, Stéphane Ducasse <stephane.ducasse@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.knoefel@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.htm...
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.htm... 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.