I fail to see how that would effect this. Adding new attributes in 
attributes.php and no where else wouldn't really do *anything* (except 
make attributes.php larger).  The other way around _would_ be a 
problem though.  Nevertheless, glad it's working again for you.

Problem is corrected.  I found where I have added several fields to 
the attributes.php but hadn't listed them in sources.php.  I added 
those 'missing' fields and now the calendar functions are working 
quickly again.



I really don't believe this was the fix but since that was the only 
change I made it seems to be the current answer.



I had rebooted client and server, signed off and back on cleared 
cached and probably a few other tasks but nothing made a difference 
until I fixed the mismatch between attributes and sources.



I'd love to hear your thoughts when you have the time.

Correct.
These were (mostly) changes to do with the kolab driver and some 
shuffling around of the schema.  There *was* a change in the default 
SQL schema though.  If you updated your sources.php file and used it 
as is, then you should also run the upgrade script 
2007-11-17-sql-schema.sql

I did find a difference but it doesn't seem relevant:



On 11.18 the turba/config/attributes.php had this for the birthday attribute:

$attributes['birthday'] = array(

     'label' => _("Birthday"),

     'type' => 'monthdayyear',

     'params' => array(1900, null, true, '%Y-%m-%d'),

     'required' => false,

);



while the 11.24 had this:

$attributes['birthday'] = array(

     'label' => _("Birthday"),

     'type' => 'monthdayyear',

     'required' => false,

     'params' => array('start_year' => 1900, 'end_year' => null, 
'picker' => true, 'format_in' => '%Y-%m-%d', 'format_out' => '%x')

);



format out is the more significant difference.  Could it be important?



The entire attributes.php and sources.php underwent a decent amount of 
changes between this time so that may be something for someone with 
more experience with the Horde system to examine as well.

OK - I've narrowed it down a bit.  Luckily I've kept backups as I've 
upgraded.  The change that's lost the speed enhancements was between 
the CVS HEAD update between 11.21 & 11.24.  The 11.18 update works 
quickly.  The 11.21 update works quickly.  The 11.24 update is *slow*.



So - it was something changed between 11.21 (fast) and 11.24 (slow.)



I'll be looking for changes between those two updates but if you find 
anything I'd appreciate hearing about it.

In other words, are you using *only* a SQL based source?  The 
enhancements only apply to SQL backends.  Make sure that when you 
updated, you didn't overwrite your config/sources.php file.  (Grabbing 
at straws here)



The only other thing I can suggest is sprinkling some debug statements 
around in lib/Driver/sql.php in the _getTimeObjectTurbaList() method 
to see if it is indeed only returning the records that you are 
interested in.

Yes - Dramatically - from almost 1 minute to load a screen to just a 
few seconds.
I am afraid not.  The last updates *I* did were dated 11.18, 11.21 & 
11.24.  I do remeber it was working before the 18th but I am not 
certain if I used the calendar feature between the 18th & 24 since I 
was traveling during that time.
I don't know what you mean by that question - so the answer is 
probably no.   :-)

I don't see anything that has changed relating to this specific 
enhancement.  Does the speed improve when you turn off the birthdays 
showing in the calendar?  Do you know specifically which cvs change 
(or even date) breaks it?  Did you by any chance add a new source?

Appears we've lost the speed enhancements.  I updated from CVS and now 
the calendar is back to loading *really* slowly again (almost 1 minute 
to load and/or to change to another month.  )



Could some changes have been made that removed/overrode the changes 
done earlier to resolve this ticket?

I dumped /turba/lib/api & Driver.php and reloaded from HEAD.



This solved the issue.  Don't know why though.

The cause of this error is corrected in CVS, but I'm not sure why you 
were even executing that function, unless you have sources other that 
SQL configured as well. (These changes only improve the birthday 
fetching from SQL sources.

I assume this has to do with this latest batch of changes.  I just 
updated from HEAD and am getting this error when trying to open 
Kronolith:

Fatal error: Cannot use object of type Horde_Date as array in 
/var/www/localhost/htdocs/h6/turba/lib/Driver.php on line 542



I've checked the .dist files for updates and I have signed off & back on.



I've missed something - obviously - but I cannot test these newest 
changes until I get it working again.  Can you provide some ideas on 
where to look?

Alright, this should do it.  Added a date range check in the SQL.   
*Should* be portable across various RDBMS, but could do with some 
testing on various platforms to be sure. Please let us know if this 
improves your speed...



Thanks!

Resolving this, since the original request was dealt with. Still would 
like to filter dates on the server side, but that is proving 
problamatic (at least with PEAR::DB and the current storage of 
birthdays in the database).

Of course, that was it.  I had updated prefs but failed to signoff/on.



Thanks.



BTW - birthdays are being included on the calendar now and they are 
much faster.  Now we will begin to - slowly - add birthdays to Turba.   
I assume as more entries are in the address book the slower the 
calendar screens will become until you finish your other enhancements?

You need to:



1) Make sure your prefs.php file is updated from prefs.php.dist

2) Logout, then back in to reload the prefs.

Sorry - jumped the gun here.  The Kronolith changes mentioned earlier 
implement a new way of choosing if you want to see birthdays, etc.   
Just found it.



The birthdays now seem to be working - trying to determine why my 
kronolith changes to show birthdays isn't being saved.



Will update later after I've more time to determine the speed 
improvement.  Currently it seems to be somewhat faster.



BTW - I no longer have a Birthday index (mentioned in one of the first 
tickets on this subject) would it help or harm having one?

Found another strange item.  I notice the 
kronolith/config/prefs.php.dist was changed when I updated HEAD.  If 
you use this new prefs. file it no longer has the external calendar 
option in it!



What's up with that?

Strange goings on.  I did the update and noticed the "M" tag before 
turba/lib/Driver.php and turba/lib/api.php which I assume means I 
modified those files on my side (which I did trying to add anniversary 
lookups) so I renamed those two files with .XX extensions and ran the 
update again.



I then turned on the option for external address books and I get .... 
nothing.  No birthday entries at all.



Attached is the output of the cvs -Pd  runs.  First section is "a" 
second second is "b".

Yes.

Wonderful!  So I just update from CVS to get this, right?



Thank you so much for your help.  I'll update, test and give you 
feedback before the end of the weekend.

Added a sql specific check for birthdays that only return items with a 
non-empty birthday field.  Still want to do some date range filtering, 
but this is a start.



Please let us know how much difference that made for you.

Yea, I've got to stop answering tickets while I'm at work without 
access to source code :)



Anyway, good point - marking it accepted then for overiding 
listBirthdays() when appropriate.

Not sure why we need that assumption - if the source doesn't have a 
field that maps to Turba's birthday attribute then listBirthdays 
should be a no-op, for starters. Seems reasonable that overriding 
listBirthdays should allow a more efficient backend-specific search. I 
do see a hitch doing date comparisons in the backend ... but we can 
format the search dates for the backend so even that should be fine.

Well - perhaps 5825 & 5826 are more related than I thought.  Including 
a configuration entry listing the 'configured' date fields would help? 
  In essence - the admin is saying that these fields will be used in 
this install would help decide whether the query should be performed 
for birthdays, anniversaries, etc. or if none listed, not at all?

This is a good idea, but makes an assumption that all the backends 
that Turba supports is able to hande such queries...which is not the 
case.  We could override the Turba_Driver::listBirthdays() method in 
(for example) the sql driver, but then we would *still* be making an 
assumption that every install will have a turba_objects table 
containing a birthday column - which is also not always true...guess 
we could somehow check for the existence of a configured birthday 
column first?

I would like to request an enhancement to the efficiency of the 
function that pulls birthdays from the Address book into the Calendar 
view.  Please see the  10/21/2007 and forward dated entries in ticket 
# 723 for a discussion, but apparently the current code reads ALL 
entries in the address book looking for birthdays.



As a "quick fix" I would think a query that builds a collection of 
address book entries that actually contain birthdays could be used to 
read from would speed up the process or building a collection of 
entries with birthdays +/- 30 days of the current days since these 
birthdays only show on calendars less than the 1 year calendar.



The symptoms are as follows:



I have added the Address Book to my external events on my calendar in 
order to have the birthdays from my address book show on my calendar.



The time to show my calendar went from 1-2 seconds to 15-20+ seconds!



I am running the latest CVS code and have about 700 entries in the 
turba_objects table.  Currently there are only about 25 of those 700 
that actually contain birth dates but that number will grow quickly now.