[Tickets #4891] api calls fail with postgres datatree without persistent connections

[bugs@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=4891
-----------------------------------------------------------------------
 Ticket             | 4891
 Created By         | stromsoe at gmail.com
 Summary            | api calls fail with postgres datatree without persistent connections
 Queue              | Turba
 Version            | 2.1.3
 Type               | Bug
 State              | Unconfirmed
 Priority           | 1. Low
 Owners             | 
-----------------------------------------------------------------------


stromsoe at gmail.com (2007-01-14 01:04) wrote:

When I run other horde applications that use the turba api calls, I end up
with a blank screen.

php 5.2.0
apache 2.0.59
postgresql 8.2.0
horde, imp, kronolith, mnemo, nag, turba - all current stable

horde is configured with postgres for the datatree.
turba is also configured to use postgres for personal address books.

The bug triggers in IMP if I am viewing an email and click on the Notebook
icon to add an email to address book.  It also triggers if I try to view an
HTML attachment with images (the call to check if the sender is in the
address book fails).

I've traced the bug as follows:

calls from Registry.php:

1. the registry function call() calls callByPackage()
2. callByPackage() calls pushApp() to push the application context
3. pushApp() calls hasPermission()
4. hasPermission() calls $GLOBALS['perms']->hasPermission()

calls from Perms/datatree.php

5. hasPermission() calls getPermissions()
6. getPermissions() calls getPermission()
7. getPermission() calls $this->_datatree->getObject()

calls from DataTree.php

8. getObject() calls getId() and feeds the results to getData() from
DataTree/sql.php

calls from DataTree/sql.php

9. getData() calls $this->_db->getRow(), which fails and returns a
PEAR_Error because the database connection no longer exists

10. immediately after the call to getRow(), Horde_Serialize::unserialize()
is called with data from $row that doesn't exist and PHP bails with a blank
screen.

There is no check for a Pear_Error after 9.

If I use persistent SQL connections I don't see this at all.  This is 100%
repeatable in my environment.