[OpenSER-Devel] trunk compilation warning

Henning Westerholt henning.westerholt at 1und1.de
Thu Oct 18 10:29:18 CEST 2007


On Wednesday 17 October 2007, Dan Pascu wrote:
>> [..]
> I'd like to come back to this issue a bit, because I think this can be
> done better.
>
> My idea is that instead of having a fixed list of db schemas to build,
> that are specified in the Makefile, we should build any db schema
> contained in a file that matches the pattern openser-*.xml
> With this is very easy for someone to add extra db schemas for extension
> modules without any need to include some extra.xml that is not present.
> All one has to do is drop in an openser-mymodule.xml file and it will be
> automatically build. If it's not there no warning will be issued.
>
> This approach has another advantage. It allows me to define the db schemas
> for different modules/extensions in different files. With extra.xml I'm
> forced to put them all together in a single file, which is suboptimal
> (just imagine I have multiple extensions but I do not want to deliver
> them all together in all cases, which will require me to manually edit
> extra.xml for each specific case).
>
> If there are no objections against this, I'll go ahead and do this.

Hello Dan,

the current approach has the advantage that it allows someone to specify which 
tables he want to use in the Makefile, other tables are not generated.

Anyway, this don't qualify for me as bugfix or tools enchancement, so its not 
possible to do this change at the moment in the trunk. So please lets keep 
the current state for now.

> -----------------------
>
> A second issue is about the database tables are created by openserdbctl.
> It's not clear to me why they have been split into standard, extra and
> presence tables. What is the benefit of not creating all the tables
> defined by the db schemas and instead have to ask the user if he wants
> presence or extra tables?
>
> I think this approach only creates more confusion among the users and has
> one serious disadvantage: it needs to remember what you answered, so that
> later can include or not those bits in further processing (this is why we
> have configuration options like HAS_EXTRA and HAS_SERWEB in openserctlrc)
> So not only has one to answer the questions, but he also need to add these
> settings in openserctlrc so that later commands like openserdbctl migrate
> do the right thing. And a second serious disadvantage is that if I create
> the tables and answer with no to presence and extra, but later decide I
> need them, I have no easy way to only create the missing tables, without
> manually feeding the corresponding *-create.sql scripts to the database,
> or doing database backup/restore operations.

Yes, you're right. Its not possible at the moment to only install the serweb 
or presence tables _without_ the core tables.

> IMO, we should create all tables for which we have a definition, with the
> sole exception of serweb which is an external application, for which we
> shouldn't even define schemas and create tables (this should stay in the
> serweb application).
>
> I see no real harm if tables defined by modules that may never be used are
> created in a database and just sit around empty.

I aggree. But here applies the same arguement as for the your first point. A 
chance like this at the current time will also create confusion amound us and 
the users. So lets disuss this after the release.

Cheers,

Henning



More information about the Devel mailing list