[asterisk-users] Simple CDRs

[Grey Man]

On Fri, Jan 9, 2009 at 3:48 AM, Steve Murphy <murf at 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.