[turba] how to simplify my turba upgrade process

[Robert P. J. Day]

On Mon, 31 Aug 2009, Michael Rubinsky wrote:

> Quoting "Robert P. J. Day" <rpjday at crashcourse.ca>:
> >
> >  i have the following turba-related tables in mysql horde:
> >
> >  * turba_objects
> >  * turba_clients
> >  * turba_customers
> >  * turba_suppliers
> >
> >  * turba_shares
> >  * turba_shares_groups
> >  * turba_shares_seq
> >  * turba_shares_users
> >
> > the first four appear to be actual address books (that first one
> > would have been better off being named "turba_employees" since
> > it's for the company employees), but that brings me to my first
> > question.
> >
> >  ignoring the "shares" stuff, does the above represent four
> > separate address books?
>
> Yes.

  good, but what threw me the first time i looked at those mysql
tables was that the name "turba_objects" somehow looked ... *special*.
as if it was some kind of turba *meta*data.  which is clearly not the
case.  it's just another address book, so having the docs constantly
refer to "turba_objects" can be really, really misleading.

> > as in, each individual address book will be represented by a
> > distinct table in the "horde" database?
>
> It depends. For the above to actually work, each address book would
> need a separate entry in sources.php

  of course.  i was simply talking about the mysql tables, nothing
more.  are you saying that i can have multiple address books all
contained in a single mysql table?  if true, that would explain the
constant references to the "turba_objects" table, if that single table
could manage all address books at once.

> >  is there anything magic about the table name "turba_objects"?
>
> It's only special in the sense that it's the name given to the table
> created by the sql creation scripts. This corresponds to the
> 'localsql' source that is included in the sources.php.dist file.

  fair enough -- it's special only in the sense that it's the
arbitrary name that was chosen as the default.

> >  as i was reading the docs, i kept running across that name as if
> > it was special.  but in the context i'm working in, it looks like
> > just another address book.  would it have been equivalent to have
> > called it, say, "turba_employees"?
>
> Sure, as long as you make the necessary changes in sources.php.

  yup, that's clear.

> > i ask this since a number of the upgrade scripts i've perused
> > refer to that table ***by exact name***.
>
> Which upgrade scripts are those?

  the scripts in turba/scripts/upgrades.  look at, for instance,
1.2_to_2.0.sql:

ALTER TABLE turba_objects ADD COLUMN object_uid VARCHAR(255);
ALTER TABLE turba_objects ADD COLUMN object_freebusyurl VARCHAR(255);
ALTER TABLE turba_objects ADD COLUMN object_smimepublickey TEXT;
ALTER TABLE turba_objects ADD COLUMN object_pgppublickey TEXT;

  clearly, that script is hard-coded with the table name and assumes
that that's the table being used.  but in *my* case, i have *four*
tables for my address books, and there's nothing in the upgrade
instructions that tells me that, in order to upgrade the schema, i
need to invoke that script against *all* my tables, right?

  i think it would make more sense if that script were modified to
accept a table name, plus the docs should make it abnudantly clear
that you need to do that schema upgrade on *all* of your address book
tables.  because that's not at all obvious right now.

> > but if that's just another mysql address book table, how does it
> > make sense for some of the upgrade scripts to specifically alter
> > the exact table "turba_objects"?  or am i misreading something
> > badly here?
>
> Not sure until I know what scripts you're talking about.

  see above.  and any other turba upgrade scripts that refer
*explicitly* to the table "turba_objects".

> > i've gone through the upgrade scripts and tried to do everything
> > necessary to bring those four tables in sync with the latest
> > schema, and it *looks* like i did that, but is there any way to
> > verify that?
>
> I think there's a misunderstanding. What, exactly, do you mean by
> "the latest schema"? The schema you use for your address books are
> completely up to you. You just need to make sure that the field
> names in your tables match the map you create in sources.php.

  if you read the upgrade instructions for turba, you're told to run a
number of scripts that modify the schema of old tables to make them
compatible with the latest version of turba.

> >  and, finally (for now), it was getting tough to follow the
> > upgrade scripts since, at one point, some step would be described
> > as "optional" while a subsequent step would *require* that to have
> > been done.  so my thought was to *completely* uninstall every
> > trace of turba (except for the 4 address books), then put it back
> > in, as long as i could eventually point it back at the 4 existing
> > address books. is that doable?
>
> Hard to tell without exact information.  Most of those upgrade
> scripts are probably share related. You don't say if you plan on
> using shares (or if you *were* using shares in your previous
> version).

  i was getting to that.  but i just want to clarify these issues
first so i don't wander too far afield in the wrong direction.

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

        Linux Consulting, Training and Annoying Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================