SQL Cleanups (Was: Duplicate requests in a session)
-Moved to devel list from user list- On Thu 31 Aug 2006 13:12, Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
Good question. Does anyone have anything against changing this?
They primary key should be a synthetic field, and not something derived directly from the packet. Calling it 'acctuniqueid' is awkward, maybe renaming it to 'radiuskey'?
It can then be used in the SQL queries as %{Acct-Unique-ID:-%{Acct-Session-id}}, which should be safe for all configuration.
This makes sense to me. I think it should be for 2.0 though as changing the name of fields in a DB schema will break compatibility. I have also been considering a number of other cleanups for 2.0 One of my pet peeves is that the mysql config file is called "sql.conf" which tends to confuse non-mysql users the first time around. This should be renamed to mysql.conf (oraclesql.conf should be renamed to oracle.conf also) I think it may even be a good idea to make a raddb/sql/*.conf structure, either that or maybe we should name the files sql.mysql.conf, sql.postgresl.conf etc. This then allows sqlippool.mysql.conf also. (Alternatively the sqlipool config should go inside the existing sql config files.) Also, before a 2.0 release I would like to sit down and bring the queries for the different SQL variants as close together as possible as they have gradually diverged over the last few years. (Much of it my fault as I have been continually adding new features to the postgresql schema :-) Thoughts? -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon <listuser@peternixon.net> wrote:
This makes sense to me. I think it should be for 2.0 though as changing the name of fields in a DB schema will break compatibility.
I'm not set on changing the name. If it's a problem, we can leave it as-is.
One of my pet peeves is that the mysql config file is called "sql.conf" which tends to confuse non-mysql users the first time around. This should be renamed to mysql.conf (oraclesql.conf should be renamed to oracle.conf also)
Let's fix that.
I think it may even be a good idea to make a raddb/sql/*.conf structure,= either that or maybe we should name the files sql.mysql.conf, sql.postgresl.conf etc. This then allows sqlippool.mysql.conf also. (Alternatively the sqlipool config should go inside the existing sql config files.)
Sure. We can also split the sql.conf file into: sql.conf - global SQL things to the site, which does driver = postgresql trace files... $INCLUDE sql/postgresql.conf for any postgres-specific things. We can nuke the "rlm_sql" prefix from the "driver" config item, and update the code to accept one or the other.
Also, before a 2.0 release I would like to sit down and bring the queries for the different SQL variants as close together as possible as they have gradually diverged over the last few years. (Much of it my fault as I have been continually adding new features to the postgresql schema :-)
Sounds good to me. I have a few other things on my agenda that I'd love to do, like have per-"listen" configuration sections, but I think that's hard. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Thu 31 Aug 2006 14:33, Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
This makes sense to me. I think it should be for 2.0 though as changing the name of fields in a DB schema will break compatibility.
I'm not set on changing the name. If it's a problem, we can leave it as-is.
Nope. No problem. Renaming a database field is trivial to do, but something that MUST be included in upgrade notes etc. I think we should take the chance to get rid of as many of the small confusing things for 2.0 as possible as we will not have another .0 release for quite a while :-)
One of my pet peeves is that the mysql config file is called "sql.conf" which tends to confuse non-mysql users the first time around. This should be renamed to mysql.conf (oraclesql.conf should be renamed to oracle.conf also)
Let's fix that.
I think it may even be a good idea to make a raddb/sql/*.conf structure,= either that or maybe we should name the files sql.mysql.conf, sql.postgresl.conf etc. This then allows sqlippool.mysql.conf also. (Alternatively the sqlipool config should go inside the existing sql config files.)
Sure. We can also split the sql.conf file into:
sql.conf - global SQL things to the site, which does driver = postgresql trace files... $INCLUDE sql/postgresql.conf
for any postgres-specific things.
We can nuke the "rlm_sql" prefix from the "driver" config item, and update the code to accept one or the other.
Thats an even better idea. I shall do it this evening.
Also, before a 2.0 release I would like to sit down and bring the queries for the different SQL variants as close together as possible as they have gradually diverged over the last few years. (Much of it my fault as I have been continually adding new features to the postgresql schema :-)
Sounds good to me.
I have a few other things on my agenda that I'd love to do, like have per-"listen" configuration sections, but I think that's hard.
-- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon <listuser@peternixon.net> wrote:
Nope. No problem. Renaming a database field is trivial to do, but something that MUST be included in upgrade notes etc.
People read those? <ducks>
I think we should take the chance to get rid of as many of the small confusing things for 2.0 as possible as we will not have another .0 release for quite a while :-)
Yes. I would like to increase the rate at which releases are made, but that depends on other things... Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Thu, 2006-08-31 at 07:33 -0400, Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
This makes sense to me. I think it should be for 2.0 though as changing the name of fields in a DB schema will break compatibility.
I'm not set on changing the name. If it's a problem, we can leave it as-is.
One of my pet peeves is that the mysql config file is called "sql.conf" which tends to confuse non-mysql users the first time around. This should be renamed to mysql.conf (oraclesql.conf should be renamed to oracle.conf also)
Let's fix that.
I think it may even be a good idea to make a raddb/sql/*.conf structure,= either that or maybe we should name the files sql.mysql.conf, sql.postgresl.conf etc. This then allows sqlippool.mysql.conf also. (Alternatively the sqlipool config should go inside the existing sql config files.)
Sure. We can also split the sql.conf file into:
sql.conf - global SQL things to the site, which does driver = postgresql trace files... $INCLUDE sql/postgresql.conf
for any postgres-specific things.
That sounds interesting. It would likely make it easier to provide some alternate configuration files for the different types of radius installs like : sql/postgresql-dialup.conf sql/postgresql-wireless.conf sql/postgresql-voip.conf Providing these along with the appropriate schema files, could significantly reduce the problems for new adopters. I believe most of these versions are available in scattered locations around the net. I am only doing using it for dialup, so I have not done much research into the other configs.
We can nuke the "rlm_sql" prefix from the "driver" config item, and update the code to accept one or the other.
Also, before a 2.0 release I would like to sit down and bring the queries for the different SQL variants as close together as possible as they have gradually diverged over the last few years. (Much of it my fault as I have been continually adding new features to the postgresql schema :-)
Sounds good to me.
Like Peter, I have been focused on PostgreSQL development, and my last significant contributions was getting the PostgreSQL equivalent to the MySQL, but that was quite a long time ago. I have also been developing another administration interface, but need to clean it up. Since I only had 3 weeks to develop it, I combined some code written for other purposes to speed the development, and want to rework what I have written now that the initial crunch is over. There are also some additional features I want to add that need to be fleshed out. Q: Is there a time frame to get submissions in for inclusion into 2.0 ?
I have a few other things on my agenda that I'd love to do, like have per-"listen" configuration sections, but I think that's hard.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- Guy Fraser Network Administrator The Internet Centre 1-888-450-6787 (780)450-6787
On Thu 31 Aug 2006 18:48, Guy Fraser wrote:
On Thu, 2006-08-31 at 07:33 -0400, Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
This makes sense to me. I think it should be for 2.0 though as changing the name of fields in a DB schema will break compatibility.
I'm not set on changing the name. If it's a problem, we can leave it as-is.
One of my pet peeves is that the mysql config file is called "sql.conf" which tends to confuse non-mysql users the first time around. This should be renamed to mysql.conf (oraclesql.conf should be renamed to oracle.conf also)
Let's fix that.
I think it may even be a good idea to make a raddb/sql/*.conf structure,= either that or maybe we should name the files sql.mysql.conf, sql.postgresl.conf etc. This then allows sqlippool.mysql.conf also. (Alternatively the sqlipool config should go inside the existing sql config files.)
Sure. We can also split the sql.conf file into:
sql.conf - global SQL things to the site, which does driver = postgresql trace files... $INCLUDE sql/postgresql.conf
for any postgres-specific things.
That sounds interesting. It would likely make it easier to provide some alternate configuration files for the different types of radius installs like :
sql/postgresql-dialup.conf sql/postgresql-wireless.conf sql/postgresql-voip.conf
Yes. A VERY good idea IMHO.
Providing these along with the appropriate schema files, could significantly reduce the problems for new adopters. I believe most of these versions are available in scattered locations around the net. I am only doing using it for dialup, so I have not done much research into the other configs.
We can nuke the "rlm_sql" prefix from the "driver" config item, and update the code to accept one or the other.
Also, before a 2.0 release I would like to sit down and bring the queries for the different SQL variants as close together as possible as they have gradually diverged over the last few years. (Much of it my fault as I have been continually adding new features to the postgresql schema :-)
Sounds good to me.
Like Peter, I have been focused on PostgreSQL development, and my last significant contributions was getting the PostgreSQL equivalent to the MySQL, but that was quite a long time ago. I have also been developing another administration interface, but need to clean it up. Since I only had 3 weeks to develop it, I combined some code written for other purposes to speed the development, and want to rework what I have written now that the initial crunch is over. There are also some additional features I want to add that need to be fleshed out.
Q: Is there a time frame to get submissions in for inclusion into 2.0 ?
Sooner rather than later?! <ducks> -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Guy Fraser <guy@incentre.net> wrote:
That sounds interesting. It would likely make it easier to provide some alternate configuration files for the different types of radius installs like :
sql/postgresql-dialup.conf sql/postgresql-wireless.conf sql/postgresql-voip.conf
Yes, please!
Q: Is there a time frame to get submissions in for inclusion into 2.0 ?
Before December. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Thu 31 Aug 2006 18:48, Guy Fraser wrote:
On Thu, 2006-08-31 at 07:33 -0400, Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
This makes sense to me. I think it should be for 2.0 though as changing the name of fields in a DB schema will break compatibility.
I'm not set on changing the name. If it's a problem, we can leave it as-is.
One of my pet peeves is that the mysql config file is called "sql.conf" which tends to confuse non-mysql users the first time around. This should be renamed to mysql.conf (oraclesql.conf should be renamed to oracle.conf also)
Let's fix that.
I think it may even be a good idea to make a raddb/sql/*.conf structure,= either that or maybe we should name the files sql.mysql.conf, sql.postgresl.conf etc. This then allows sqlippool.mysql.conf also. (Alternatively the sqlipool config should go inside the existing sql config files.)
Sure. We can also split the sql.conf file into:
sql.conf - global SQL things to the site, which does driver = postgresql trace files... $INCLUDE sql/postgresql.conf
for any postgres-specific things.
That sounds interesting. It would likely make it easier to provide some alternate configuration files for the different types of radius installs like :
sql/postgresql-dialup.conf sql/postgresql-wireless.conf sql/postgresql-voip.conf
Providing these along with the appropriate schema files, could significantly reduce the problems for new adopters. I believe most of these versions are available in scattered locations around the net. I am only doing using it for dialup, so I have not done much research into the other configs.
Reorganisation of the SQL config files. Hold onto your hat. CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: sql.conf CVS: Added Files: CVS: sql/mssql-dialup.conf sql/mysql-dialup.conf CVS: sql/oracle-dialup.conf sql/postgresql-dialup.conf CVS: sql/postgresql-voip-postpaid.conf CVS: Removed Files: CVS: mssql.conf oraclesql.conf pgsql-voip.conf postgresql.conf CVS: ---------------------------------------------------------------------- Have fun :-) -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
participants (3)
-
Alan DeKok -
Guy Fraser -
Peter Nixon