[turba] how to simplify my turba upgrade process

[Michael Rubinsky]

Quoting "Robert P. J. Day" <rpjday at crashcourse.ca>:

> 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.

Can you point me to where in the docs referring to turba_objects is  
misleading you?

>
>> > 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?

Well, it depends on what you mean my multiple address books. A single  
address book table can contain the personal address books for each  
user, for example. If enabling 'shares', then each user can create  
additional address books and manage the permissions to those address  
books themselves and all the "objects" (contacts/groups) would exist  
in that single 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.

Well, not entirely arbitrary, the name makes semantic sense, it  
contains entries describing a single Turba_Object.

>
>> >  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?

That name is hard coded in that upgrade script since it is modifying  
the table that is provided by horde as a default/example. Again, you  
can use *any* schema that you want for your address books. There is  
nothing forcing you to use the schema provided "out of the box" by  
Turba. If you are not using the turba_objects table (and therefore not  
using the provided 'localsql' example configuration) then you this  
upgrade script doesn't do anything for you anyway. Put another way, if  
you create your own schema, then you are responsible for creating the  
tables. If, for whatever reason you decided to create an additional  
sql table that is to contain the exact same schema as the one that  
Turba provides in the turba_objects table and configured by 'localsql'  
AND you want to mirror those changes as the turba_objects table is  
changed from time to time, then I guess your answer is 'yes, you  
should run those schema changes on your other tables.


>
>   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.

That's not true. See above.

>
>> > 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".

see above for the reason why.


>> > 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.

If using the turba_objects schema, yes. The idea is a user install  
Turba, uses the provided schema, does no customization.  The next  
version comes out with improvements to the schema and code. Since this  
person installed the provided schema, it makes sense for this person  
to run these schema changes. If however, a person installs Turba and  
uses his/her own custom schema, then these scripts do nothing for this  
person. We cannot attempt to alter a schema that was not installed by  
us.


Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Time just hates me. That's why it made me an adult." - Josh Joplin