On Fri, Jan 9, 2009 at 3:48 AM, Steve Murphy <m...@digium.com> wrote: > > But, since it is timestamp based, and unique in that the final part was > incremented per request in the same sec, it made a great item to sort > on, and allowed me to implement linkedID's.
Again that's mixing fields that shouldn't be. The calldate or starttime can be used to sort the CDRs on creation time. If you're going to call a field uniqueid surely a good effort should be made to make it live up to its name. If it's intended to be a sequenceid then that's what it should be called. > I guess I could simply have > used a simple integer for a linkedID, and had a routine somewhat like > the one that coughs up the uniqueID's, just use a lock to provide > a number that is incremented safely, (atomic_fetchadd_whatever) > and hand it out. Then I could have > used a numeric comparison. Might be faster. Maybe Someday... > > But, it is NOT a number. It's got a period in it but uuids usually > have dashes. It's a string. Why you would rip off a system name, I > cannot guess, unless you really want or need to deal with it as a > number. > > My advise is not to. I have no prob with uuids, except that they are > 36 bytes, and overkill for uniqueness. linkedID + system name would be > totally sufficient; One glance at the linkedID will tell you immediately > what sys it came from, if you did that. > > But it's quite legitimate to want to use UUID's. I have no idea how much > processing power they take to be generated, probably not much. There's > pros and cons... I don't deal with UUIDs as a number or string I deal with them as a UUID (a UUID is a type in OO langauages). That's the point I'm trying to get across. Every modern high level language already has constructs to deal with UUIDs AND it's such a dead easy way to generate a unique id, it's one line of code. By making it a string or integer or something else you're making it harder for people to deal with in their billing engines and it's not actually making the field any more unique than it would be as just a UUID. I don't understand why you want to combine server name and/or a timestamp with the unique id? If a user wants to know or sort on server name then why not provide a dedicated field in the CDR for that? I'm not being anal here. I'm not the only one that has raised this and time and time again it's cropped up on the mailing list where users have been burnt because they relied on uniqueid being unique. Perhaps it would be worth soliciting views from the user list on what people's preference would be for the uniqueid field? Maybe there is a super efficient unique id generation approach that uses less than 36 bytes but what's going to cost the most: people's time in accommodating the super cleverness in their many and varied systems (instead of a UUID that's well understood with existing constructs) or storing 36 bytes per CDR? Regards, Greyman. _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users