Tickets :: [#2298] Move history to its own table

6.0.0-beta1

7/20/25

Summary	Move history to its own table
Queue	Turba
Queue Version	HEAD
Type	Bug
State	Resolved
Priority	1. Low
Owners	chuck (at) horde (dot) org
Requester	leena.heino (at) uta (dot) fi
Created	07/19/2005 (7306 days ago)
Due
Updated	07/20/2005 (7305 days ago)
Assigned	07/19/2005 (7306 days ago)
Resolved	07/20/2005 (7305 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

07/20/2005 09:50:46 PM	Jan Schneider	Comment #15	Reply to this comment
... though I have to say it's not that huge a change. The History class is pretty simple and this doesn't change the API at all. The huge change is in the data storage, not in the API, and that's what admins care about, rather not about the API.

07/20/2005 09:44:05 PM	Chuck Hagenbuch	Comment #14	Reply to this comment
... though I have to say it's not that huge a change. The History class is pretty simple and this doesn't change the API at all.

07/20/2005 09:43:01 PM	Chuck Hagenbuch	Comment #13	Reply to this comment
I was very careful to make sure this doesn't break BC. But I'm okay with it waiting for 3.1 if we're focusing on 3.1 soon.

07/20/2005 09:08:08 PM	Jan Schneider	Comment #12	Reply to this comment
I apparently forgot to add the upgrade script, it's there now. Why not merge it? Because it's a huge change, requiring upgrade scripts to be executed, probably breaking BC somewhere. Something we never did in a bug fix release and shouldn't start doing. We should rather concentrate on x.1 releases once the current bugfix releases are out.

07/20/2005 09:08:04 PM	Jan Schneider	Comment #11	Reply to this comment
I apparently forgot to add the upgrade script, it's there now. Why not merge it? Because it's a huge change, requiring upgrade scripts to be executed, probably breaking BC somewhere. Something we never did in a bug fix release and shouldn't start doing. We should rather concentrate on x.1 releases once the current bugfix releases are out.

07/20/2005 06:52:56 PM	leena (dot) heino (at) uta (dot) fi	Comment #10	Reply to this comment
As you saw in the datatree monster sql the query took something like 54 seconds to complete. And this query is run every time the user adds an address to the address book or creates a new event or task or note. I've now tested this with horde head and framework 3 versions. The task was adding a single entry to address book or a task to calendar: Horde framework 3 version with history in a datatree: 2 minutes. Horde head version with history in a separate table: 2 seconds.

07/20/2005 02:32:18 PM	leena (dot) heino (at) uta (dot) fi	Comment #9	Reply to this comment
I apparently forgot to add the upgrade script, it's there now. Why not merge it? Is there a way to try separate history table code if framework 3. The history information in the DataTree is killing the system in terms of performance. As you saw in the datatree monster sql the query took something like 54 seconds to complete. And this query is run every time the user adds an address to the address book or creates a new event or task or note.

07/20/2005 01:22:55 PM	Chuck Hagenbuch	Comment #8	Reply to this comment
I apparently forgot to add the upgrade script, it's there now. Why not merge it?

07/20/2005 07:07:10 AM	Jan Schneider	Comment #7	Reply to this comment
There is no upgrade script yet, only the SQL script for creating the table. And we shouldn't merge this to 3.0.5.

07/20/2005 04:00:18 AM	Chuck Hagenbuch	Comment #6 Version ⇒ HEAD	Reply to this comment
Only for HEAD right now, but I'll merge it to Horde 3.0.5/6 if it works well.

07/20/2005 03:59:44 AM	Chuck Hagenbuch	Comment #5 State ⇒ Resolved	Reply to this comment
Okay, driver rewritten and upgrade script added. Let's see how that does.

07/19/2005 09:48:35 PM	Chuck Hagenbuch	Assigned to Chuck Hagenbuch

07/19/2005 09:48:23 PM	Chuck Hagenbuch	Comment #4 Summary ⇒ Move history to its own table State ⇒ Assigned	Reply to this comment
Yup, that's a monster query. Nice. I'm actually already working on moving Horde_History to use its own SQL table instead of using DataTree. Should help a bunch.

07/19/2005 05:46:44 PM	leena (dot) heino (at) uta (dot) fi	Comment #3 New Attachment: datatree-monster-sql.txt	Reply to this comment
read horde/docs/PERFORMANCE, and don't post vague bug reports that don't even tell us about the query you're blaming for the problem. I've read horde/docs/PERFORMANCE, thank you for providing it. Attached is the datatree monster sql. This is from MySQL's slow query log.

07/19/2005 04:15:00 PM	Chuck Hagenbuch	Comment #2 State ⇒ Not A Bug	Reply to this comment
read horde/docs/PERFORMANCE, and don't post vague bug reports that don't even tell us about the query you're blaming for the problem.

07/19/2005 10:09:25 AM	leena (dot) heino (at) uta (dot) fi	Comment #1 Priority ⇒ 1. Low Type ⇒ Bug Summary ⇒ adding addresses is abysmally slow Queue ⇒ Turba State ⇒ Unconfirmed	Reply to this comment
Each adding of address to address book seems to query DataTree and if you have large localsql like address book then this SQL query is abysmally slow. This monster SQL query had something like 18000 OR and 9000 LIKE parameters. Is there some way to disable DataTree in turba with localsql like address books. Or is there some way to prune DataTree.