Tickets :: [#5304] ldap backend dirty prefs

6.0.0-beta1

8/9/25

Summary	ldap backend dirty prefs
Queue	Horde Framework Packages
Queue Version	HEAD
Type	Enhancement
State	Rejected
Priority	1. Low
Owners	Horde Developers (at)
Requester	vincent.vinet (at) revolutionlinux (dot) com
Created	04/25/2007 (6681 days ago)
Due
Updated	05/12/2007 (6664 days ago)
Assigned	04/26/2007 (6680 days ago)
Resolved	05/12/2007 (6664 days ago)
Milestone
Patch	No

05/12/2007 08:53:01 PM	Chuck Hagenbuch	Comment #6 State ⇒ Rejected	Reply to this comment
All of the behavior you describe (prefs change, they get set as dirty, they are stored) is normal. If I'm misunderstanding please update the ticket and we can reopen it.

05/10/2007 09:30:15 AM	Jan Schneider	Comment #5	Reply to this comment
Ping?

04/26/2007 03:52:45 PM	Chuck Hagenbuch	Comment #4 State ⇒ Feedback	Reply to this comment
Why are you locking the last_login pref?

04/26/2007 01:57:48 PM	jmdault (at) revolutionlinux (dot) com	Comment #3	Reply to this comment
The question is rather, why are they being marked dirty? That should be fixed instead working around the symptoms. - The Last Login parameter is set when a user logs in. When it changes (ie, at login), it is set as dirty. - Some values get set via LDAP hooks (Name, e-mail adresses, etc). When the hooks set these variables, they automatically get set as dirty. It's normal that they get set dirty. What's not normal is that the preference system tries to store them. Regards, Jean-Michel

04/26/2007 12:05:37 PM	Jan Schneider	Comment #2 Assigned to Horde Developers State ⇒ Assigned	Reply to this comment
The question is rather, why are they being marked dirty? That should be fixed instead working around the symptoms.

04/25/2007 01:50:32 PM	vincent (dot) vinet (at) revolutionlinux (dot) com	Comment #1 Priority ⇒ 1. Low State ⇒ New New Attachment: ldap.php.diff Queue ⇒ Horde Framework Packages Summary ⇒ ldap backend dirty prefs Type ⇒ Enhancement	Reply to this comment
Using hooks and a ldap backend, locked preferences are often marked as being dirty. When storing preferences into the ldap server, the backend thus constantly tries to store those dirty prefs. On a server with 30,000+ users, this is a very severe performance hit on the ldap server. The patch thus filters the dirty prefs before attempting to store, letting through only the prefs which are not locked.