Summary:	ASTERISK-01505: [patch] Centralise IAX Friends and SIP friends into one table and add the ability to enable and disable users
Reporter:	nix (nix)	Labels:
Date Opened:	2004-04-29 17:03:25	Date Closed:	2011-06-07 14:04:40
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) chan_iax2_c_centralised_friends.diff ( 1) chan_sip_c_centralised_friends.txt ( 2) friends_my.sql
Description:	This patch centralises the IAX Friends and SIP friends SQL tables into one "friends" table and adds the ability to enable and disable users without deleting them from the table.
Comments:	By: nix (nix) 2004-04-29 17:34:14 The IAX2 patch is well tested but I am not using SIP. Can someone who is please test it. The only thing that has changed is the table structure and the SQL queries so it should be ok. By: Olle Johansson (oej) 2004-05-03 15:56:27 I think this is the wrong way to go - adding even more fields to the table. For SIP to be really working well, we have to add several fields... I would like to split instead. Have one common user/auth table and then separate tables for SIP, IAX2 and other channels. By: Mark Spencer (markster) 2004-05-03 21:40:32 I'm thinking that this sort of stuff should be suspended in favor of the res_data sort of arrangement which should unify all this much more tightly together. By: nix (nix) 2004-05-11 15:57:08 The is no disadvantage to adding extra fields to an existing database table as long as you don't use "SELECT *" in your code. (My previous patch which cleaned that up has already been applied). You simple select the fields you require. On the contrary, having multiple tables makes the SQL queries slower because you then have to use JOIN to get all the info you require OR you have to make multiple queries. Why would you want to make Asterisk LESS efficient?? While ever there is a ONE TO ONE relationship between USER and SIP/IAX peer then there is no reason to split into separate tables. (Infact its crazy to do so!) Unless the existing code is going to be removed entirely I believe this patch should go in. There is no speed disadvantage (indeed it should be faster as it will cache better with only one table), and it makes the whole thing simpler to understand and use therefore the only disadvantage is the fact the it breaks backward compatibility with the old DB schema, which only a very limited number of people are using in any case.. By: Olle Johansson (oej) 2004-05-11 16:29:15 Suspended while awaiting other changes. By: nix (nix) 2004-05-13 03:47:20 What are the changes that this patch is "waiting" for and why? I does not affect anything outside of SIP and IAX friends, and should not wait for res_data or any of the other new code that is being developed, as it is unrelated. By: Olle Johansson (oej) 2004-05-13 07:39:03 Nix, find us on the IRC to discuss this. Basically we want to move all SQL queries out of the channels. In the channel, we want to have functionality that doesn't depend on type of configuration - database or config files.