On Thu 31 Aug 2006 18:19, Guy Fraser wrote:
On Thu, 2006-08-31 at 12:31 +0300, Peter Nixon wrote:
Good question. Does anyone have anything against changing this?
-Peter
On Thu 31 Aug 2006 10:11, Santiago Balaguer García wrote:
Thanks James, I don't figure out to use primary key solves the problem of duplicate keys. I had in radacct as primary key <<radacctid>> but now I am going to have <<acctuniqueid>>.
This proble cause a new thread: why radacctid is the primary key of radacct table instead od acctuniqueid?
I used a slightly different solution in my PostgreSQL implementation :
ALTER TABLE ONLY radacct ADD CONSTRAINT radacct_unique_session UNIQUE ( username, nasipaddress, nasportid, acctsessionid );
After looking at this again, a unique constraint (or primary key) on "acctuniqueid" will give exactly the same behaviour as you have here with much lower load on the database. The default acct_unique looks like this: acct_unique { key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port" } Which has Client-IP-Address as well, but that is trivial to change if you want the same behaviour. It appears that the best way to enforce unique data in the database is to use the "acctuniqueid" however, the next question is: Should we be trying to ensure unique records at runtime or should that be left to post processing? I know than most people "expect" the records to be unique, but is that a realistic expectation? I have a pair of NAS in failover config (Rather large Ciscos running the absolute latest IOS technology release) which send the exact same values in every request: NAS-Port-Type = Virtual NAS-Port = 60000 NAS-Port-Id = "GGSN" Now, while this is not ideal, given that the NAS-Port-Type is Virtual it seems to be legal. Given that I have several thousand users all with identical usernames the default "acctuniqueid" is going to have exactly the same amount of uniqueness as the Acct-Session-Id as all other values are fixed (With the exception of when a NAS failover occurs). Now in my case, I do have other things that I can add to make things more unique (Calling-Station-Id, 3GPP-Charging-ID, 3GPP-IMSI etc) but the point is that I think we are going to trade one type of problem for another. (Now we have people asking why their records aren't unique, later we will have certain sets of people asking why half their records don't appear in the database) Is that a good or a bad tradeoff? I am leaning towards good, but its pretty close to even money.. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc