[pkg-horde] Bug#810858: Bug#810858: Bug#810858: webmail-install and horde try to create db schema multiple times + wrong schema version

[Ivan Sergio Borgonovo]

On 01/14/2016 03:48 AM, Mathieu Parent wrote:

OK, some more info.

aptitude show report the same version for testing, unstable and 
experimental for kronolith:
Version: 4.2.11-1

>> horde=# select * from kronolith_schema_info ;
>>   version
>> ---------
>>        17
>> (1 row)

> This should be 26 instead.
> Ref: https://github.com/horde/horde/tree/master/kronolith/migration

I would expect a 23 since it is the largest update I can find in
/usr/share/horde/kronolith/migration

but actually that upgrade isn't applied and there is no index on 
event_baseid.

> Does the 'kronolith_sharesng' table have a 'share_parents' column
> (added in step 17)?
> Does the 'kronolith_events' table have the 'event_category' column
> (removed in step 18)?

Yep. Upgrades get applied till 17. There is a 
kronolith_sharesng.share_parents column and also a 
kronolith_events.event_category

> Can you run "horde-db-migrate --debug kronolith up"?

root at caronte:/usr/share/horde/kronolith/migration# horde-db-migrate 
--debug kronolith up
[  INFO  ] Migrating DB up.
2016-01-14T11:49:59+00:00 DEBUG: SQL  (0.0004s)
	SHOW max_identifier_length
2016-01-14T11:49:59+00:00 DEBUG: SQL  (0.0004s)
	SHOW search_path
2016-01-14T11:49:59+00:00 DEBUG: SQL  (0.0042s)
	SELECT tablename FROM pg_tables WHERE schemaname IN ('"$user"','
	  public')

^^^^^^^^^^^^^^^^^^^^
I think I got it...

What really get executed is:
SELECT tablename FROM pg_tables WHERE schemaname IN ('"$user"','
	  public')

In the actual SQL statement there is an extra white space before public!

The problem should be here
foreach (explode(',', $this->getSchemaSearchPath()) as $p) {
   $schemas[] = $this->quote($p);
}
$p should be trimmed before. Anyway I find this way error prone.


I don't know if this went under the radar just because pg is seldom used 
with horde. I still don't get why moving from one update to the other 
didn't trigger this problem.

It's a pretty long time I havent written more than a couple of lines in 
PHP and I'm not that familiar with the horde codebase.

Sorry for thinking the problem was in packaging and not upstream.
I initially thought it was a problem of mixed versions in the repo.


BTW if you're going to report the bug upstream a more standard way to 
get the visible tables would be:

SELECT table_name FROM information_schema.tables WHERE table_schema = 
ANY (CURRENT_SCHEMAS(false));

This omit the $user schema if there is no $user schema... so it shows 
what can *actually* be seen from the current search_path

CURRENT_SCHEMAS() is available at least starting from pg 8.0 and 
information_schema is supported from 7.4
Postgres 8.0 is over 10 years old.

This method could be used even to retrieve indexes() so to completely 
get rid of getSchemaSearchPath()

Otherwise, let me know if I've to report it upstream and if you know... 
to which horde component.

thanks


>>
>> horde=# select * from imp_schema_info ;
>>   version
>> ---------
>>         3
>
> This looks ok.
> Ref: https://github.com/horde/horde/tree/master/imp/migration
>
> Regards
>

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it