[OpenSER-Devel] SF.net SVN: openser: [3972] trunk

Dan Pascu dan at ag-projects.com
Fri Apr 4 00:58:08 CEST 2008


On Friday 04 April 2008, Daniel-Constantin Mierla wrote:
> On 04/03/08 23:47, Dan Pascu wrote:
> > On Thursday 03 April 2008, Daniel-Constantin Mierla wrote:
> >> to understand from here that developers of  openser should provide
> >> flexibility and have the column names as parameters but not the same
> >> for other applications (being a bit nasty this time ... ;-) )
> >
> > There was no mention that those application are configurable or not
>
> I didn't say it was such mention. It is a personal conclusion. If you
> look back in time, we faced two contradictory issue:
> - being too much flexible, making things too complex and hard to
> understand some time
> - not being flexible enough, by letting other systems to take care of
> stuff they can solve
>
> One should not take care about column names as long as there are views
> support, but some do not like it this way, and should be able to have
> customizable column names. And do not take anything personally, I am
> among these. And this is just one example.

To make things clear, I do not disagree with you. The only reason I made 
my comment is because I found the nasty comment you made uncalled for in 
the context. Also because I do not think things are black and white only. 
I do not believe that jumping from the "everything is configurable" 
bandwagon to removing almost every control over the database structure is 
the way to go. Some of the db configuration options are useful once in a 
while and would be helpful to have around. Otherwise, I agree that having 
options to set every column name in a table is over the edge. I never 
liked that and if they're to be gone I would hardly miss them, if any. 
Especially for the internal tables, they should have zero configuration. 
But I maintain my opinion that with tables that interface with the rest 
of the system, like the subscriber table, it may be useful to have some 
options to customize them. Then again, I guess you're right and we can 
use a view in the end. One example that is useful is to have a different 
location/domain table to be able to run a different openser on the same 
database for testing purposes, without interfering with the production 
server. I'm sure others may find other examples of things that would be 
missed if removed. Maybe making an inquiry on the mailing lists of which 
db options (table and column names) people actually use would give us a 
better idea of what can be removed.

Anyway, to reiterate the original point, because we have drifted away with 
the discussion, I would prefer to see a solution that fixes the problem, 
rather than a workaround, that later will most likely need to be done 
again in some other module/table if a new database backed is added or a 
new version of a database introduces a conflicting internal keyword.

-- 
Dan



More information about the Devel mailing list