On Wednesday 17 October 2007, Henning Westerholt wrote: > Hello Dan, > > this is meant to be an extension point for the db schemas. E.g. you > must only copy a extra.xml file to db/schema, and its included. If the > file is not present, a non fatal (but misleading) warning will be > generated. This is generated from xsltproc, a better message would be: > > Notice: Optional entity "extra.xml" not included. > > > Sure, we could comment this out, but then people must patch the > openser-extensions.xml file. At the last time this issue was discussed > we're decided that this is also not optimal.
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. ----------------------- 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. 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. -- Dan _______________________________________________ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
