On Thu, Jan 28, 2010 at 10:34 AM, Tibor Simko <[email protected]> wrote: > On Thu, 28 Jan 2010, Victor Engmark wrote: >> Otherwise I guess we'll have to parse >> tabcreate.sql to make sure we get all of them. > > All the ones from tabcreate.sql are in tabdrop.sql. The problem is with > dynamic tables, created on run time by the admins, such as new ``book > price'' index, etc. See my other email.
That's odd, because I would have thought at least inveniocfg would be aware of the tables /it/ has created, which doesn't seem to be the case (--load-webstat-conf creates table staEVENT01, which is not removed by --drop-tables). >> I guess I'd vote to drop the schema anyway, since auxiliary tables >> should be in a different schema to avoid namespace collisions when >> upgrading. > > This would be dangerous, since some Invenio installations can choose > storing their custom tables we don't know anything about. E.g. some > Invenio installations use their own submission systems, not WebSubmit. > inveniocfg --drop-tables should drop only tables managed by Invenio > core. Who is going to rewrite all the code that we use to create dynamic tables, so that Invenio tables are recorded somewhere? Or should we use a Perl / Python script to extract all "create table" statements from the code? Are there any other options? -- Victor Engmark
