[asterisk-users] Simple CDRs

[Steve Murphy]

On Fri, 2009-01-09 at 01:40 +0000, Grey Man wrote:
> On Thu, Jan 8, 2009 at 7:22 PM, Asterisk Development Team
> <asteriskteam at digium.com> wrote:
> > Actually I could see appending a 'servername' to the UUID as useful in a
> > clustered environment. Every time I don't think I need to do that, I end
> > up having to do it. And since this would be a configurable appendage, it
> > shouldn't hurt anything.
> 
> I would argue against that. If the server name is useful in the CDR
> then add another field for it. I for one load CDRs to and from a
> database using a typed langauge and would be utilising the UUID field
> as a specific UUID type. If the server name has been tacked on I'll
> need to do some string parsing to take it off. That aside I don't
> quite understand the reluctance to rely on the uniqueness of a UUID. I
> like the wikipedia description (http://en.wikipedia.org/wiki/UUID)
> where a clash in randomly generated UUID has a probability greater
> than 10^36 whereas the probability of Earth being hit by a meteor is
> estimated as one in 17 billion.
> 
> Where I and I'm sure others want to use the current "uniqueid" CDR
> field is as the primary key in a database. Being able to rely on at
> least one field in the CDR being unique solves a lot of probelms for
> billing engines such as if the billing engine stops and starts has a
> particular call been billed or not. At the moment the "uniqueid" is
> next to useless for those of us putting CDRs into a database.
> 

As to the 'old' uniqueID, I agree, it was of extremely limited use.
Firstly, it was not really unique. In several xfer situations, you would
end up with two cdrs that had the same uniqueID, because of the way
the the CDRs were transferred during a masquerade, methinks. So you
couldn't use it as a 'unique' key -- the row # would be better. And
it couldn't really even be used to tie CDRs together in any useful way.

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. 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...

just a thought,

murf


> Regards,
> 
> Greyman.

-- 
Steve Murphy <murf at digium.com>
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20090108/5603359e/attachment.bin