> Am 20.05.2015 um 18:06 schrieb Henrik Johansen <[email protected]>: > >> >> On 19 May 2015, at 4:52 , Norbert Hartl <[email protected] >> <mailto:[email protected]>> wrote: >> >> Henry, >> >>> Am 19.05.2015 um 13:06 schrieb Henrik Johansen >>> <[email protected] <mailto:[email protected]>>: >>> >>> Hi! >>> I made some (imho) improvements to the OID implementation, if someone with >>> write access would find time to review/commit the attached package, I'd be >>> grateful. >>> >>> The commit message: >>> Make OID implementation more compatible with the description in >>> http://docs.mongodb.org/manual/reference/object-id/ >>> <http://docs.mongodb.org/manual/reference/object-id/>. >>> >>> - Use the UNIX epoch instead of Smalltalk epoch for timestamp part, store >>> BE so it's pseudo-sortable by time (also, you can use getTimestamp() in >>> mongo shell and get a sensible value) >> >> Agreed with unix epoch. The old value was in BE also which seems to be the >> right choice. >> >>> - Use a per-session ID instead of localhost name for machine >>> identification. localhost name is far from unique on some platforms (always >>> 'localhost' on Macs), better with a unique ID per image session. >> >> I do not agree. "NetNameResolver localHostName" does not return localhost >> for me. And I'd rather think the NetNameResolver does not work properly on >> Macs (not returning gethostname) instead of taking it as a reason to tweak >> client code. > > Hmm, yes, it seems localHostName could be implemented better in a way that > works on all platforms. > Instead of using the dedicated primitives > (primHostNameSize/primHostNameResult:), it tries to lookup the > localHostAddress using DNS... > On OSX, primLocalAddress was changed to always return the loopback address so > one avoids ambiguities with multiple interfaces, thus, 'localhost'. > I've commit a fixed version to the Pharo 4.0 inbox. > Thanks. But I think pharo 4.0 inbox is more or less closed and you should put it in pharo 5.0 inbox.
> I still don't really see the value in using it over a random number that > changes when the image goes through a restart cycle, as you can't really do > anything useful with it anyways, and the docs do not enforce any specific way > of obtaining it. > Yes, you are right. I don't have strong reasons to keep it the old way. It was just my way of asking "if it is not important why did you change it then?" >> The id per Session wouldn't have any value because there is also a process >> id which gives you more or less the same thing. > > Just to be clear; when I said session, I meant image session, not > db-connection session. > My thinking was that, when you can't actually use it to distingush clients > anyways, a somewhat-guaranteed-to-be-unique machine id per image > would be a better choice than guaranteed-to-be-identical for all users on > Macs. I did understand what you mean. But I don't know when Session is accessed at all. So I assumed that as long as I don't save the image the session will always be created newly on image start. So it is comparable to the process id. That is set on image start and finished on image quit as well. Ok, I've added you to MongoTalkTeam. Just upload the version you find feasible yourself. Norbert > >> >>> - Counter initialized with a random value. >>> >> Good idea. > > A bit more effort to do this if we stick to localHostName, as I piggybacked > on the unused random bits in the UUID used to replace machineIdentifier for > that, the other ways of getting random numbers in a cross-platform manner is > rather hit-and-miss, both wrt quality and performance. >> >>> As an added bonus, [OID new] bench should see a ~10% increase in >>> performance. >>> >> Even better. :) >> >> What do you think? >> >> I can make you a commiter on the MongoTalk repo. What's your username? > > henriksp is my user name. > > I tinkered some more, at the cost of readability, additional optimizations > (by removing temporary object creations), can result in an order of magnitude > more executions during a simple #bench test. > Whether one actually needs to create 200k UIDs/second instead of 20k is > another question, but in my experience, DB-interfaces can never be *too* low > overhead... > > Cheers, > Henry
