Hi Jonathan,
More or less this is the whole idea - many openser admins configures a different additional set of fields in the subscriber table, based on the needs of some provisioning tools. Of course, we cannot find a common set for this extra (non-openser) fields, so the most clear way to do it is to keep in the openser default DB struct only the fields that are used by openser. Then, anybody may "customize" the tables, based on his particular needs, without conflicting with the "particular" needs of somebody else ;)
Regards, Bogdan
Jonathan K. Creasy wrote:
I have applications that use this to display information to the customer (CDR data for example). You may still want to take it out but I just wanted to speak up that there could still be valid use for it.
-Jonathan
-----Original Message----- From: users-bounces@lists.openser.org [mailto:users- bounces@lists.openser.org] On Behalf Of Bogdan-Andrei Iancu Sent: Thursday, February 21, 2008 3:50 AM To: Henning Westerholt Cc: users@lists.openser.org Subject: Re: [OpenSER-Users] What is "timezone" field in "subscriber" table for?
Hi Henning,
I would definitely say so.
Thanks and regards, Bogdan
Henning Westerholt wrote:
On Thursday 21 February 2008, Bogdan-Andrei Iancu wrote:
Hi Inaki,
Right - this field is more or less used only by serweb (cdr
purposes) -
openser is not using it at all.
Hi Bogdan,
so i guess its safe if i remove this from trunk?
Henning
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
El Wednesday 27 February 2008 10:10:31 Bogdan-Andrei Iancu escribió:
Hi Jonathan,
More or less this is the whole idea - many openser admins configures a different additional set of fields in the subscriber table, based on the needs of some provisioning tools. Of course, we cannot find a common set for this extra (non-openser) fields, so the most clear way to do it is to keep in the openser default DB struct only the fields that are used by openser. Then, anybody may "customize" the tables, based on his particular needs, without conflicting with the "particular" needs of somebody else ;)
I agree 100%.
Just a question: what about OpenSer upgrading? will the upgrade script need to re-create the subscriber table (so remove the custom colums added by the user)?
Regards.
Iñaki Baz Castillo writes:
Just a question: what about OpenSer upgrading? will the upgrade script need to re-create the subscriber table (so remove the custom colums added by the user)?
don't put your extra subscriber field in subscriber table, but in another table, e.g., subscriber_info, table, which also has username and domain (or id) fields.
-- juha
El Miércoles, 27 de Febrero de 2008, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
Just a question: what about OpenSer upgrading? will the upgrade script need to re-create the subscriber table (so remove the custom colums added by the user)?
don't put your extra subscriber field in subscriber table, but in another table, e.g., subscriber_info, table, which also has username and domain (or id) fields.
Yes, but that is not very useful since it breaks the possiblity of loading custom fields in "subscriber" table with "load_credential()" function after authentication :(
Hi Iñaki,
The DB migration script (from 1.3 to 1.4) will just not migrate these removed columns in the new DB. Of course you can move them manually if interested in maintaining them.
In the devel version, the change affects directly (openserctl script) the db_text support as the columns from the subscriber table are addressed by index, instead of name....
Regards, Bogdan
Iñaki Baz Castillo wrote:
El Wednesday 27 February 2008 10:10:31 Bogdan-Andrei Iancu escribió:
Hi Jonathan,
More or less this is the whole idea - many openser admins configures a different additional set of fields in the subscriber table, based on the needs of some provisioning tools. Of course, we cannot find a common set for this extra (non-openser) fields, so the most clear way to do it is to keep in the openser default DB struct only the fields that are used by openser. Then, anybody may "customize" the tables, based on his particular needs, without conflicting with the "particular" needs of somebody else ;)
I agree 100%.
Just a question: what about OpenSer upgrading? will the upgrade script need to re-create the subscriber table (so remove the custom colums added by the user)?
Regards.
-
Bogdan-Andrei Iancu -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
jh＠tutpro.com