hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
Modified Files: pcache.c 1.177 -> 1.178
Log Message: ITS#6251 framework for TTR. refresh not yet implemented.
At the moment the idea for implementing refresh is to refactor syncrepl_entry() so that we can reuse the bulk of it. (Mainly the code that generates an appropriate Modify request based on the difference between the local entry and the remote entry.)
Detecting renames will be trickier since the cache typically won't have any entryUUIDs. I think we'll simply have to treat it as a Delete / Add...
hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
Modified Files: pcache.c 1.177 -> 1.178
Log Message: ITS#6251 framework for TTR. refresh not yet implemented.
At the moment the idea for implementing refresh is to refactor syncrepl_entry() so that we can reuse the bulk of it. (Mainly the code that generates an appropriate Modify request based on the difference between the local entry and the remote entry.)
Detecting renames will be trickier since the cache typically won't have any entryUUIDs. I think we'll simply have to treat it as a Delete / Add...
... which makes sense for a cache, all in all.
Or, as implementing this feature seems to move towards on-demand sync replication, we could always include entryUUID and entryCSN in the requested attributes, e.g. by implicitly adding them to the attrsets.
p.
masarati@aero.polimi.it wrote:
hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
Modified Files: pcache.c 1.177 -> 1.178
Log Message: ITS#6251 framework for TTR. refresh not yet implemented.
At the moment the idea for implementing refresh is to refactor syncrepl_entry() so that we can reuse the bulk of it. (Mainly the code that generates an appropriate Modify request based on the difference between the local entry and the remote entry.)
Detecting renames will be trickier since the cache typically won't have any entryUUIDs. I think we'll simply have to treat it as a Delete / Add...
... which makes sense for a cache, all in all.
Or, as implementing this feature seems to move towards on-demand sync replication, we could always include entryUUID and entryCSN in the requested attributes, e.g. by implicitly adding them to the attrsets.
Yes, but that's only viable if the target server supports entryUUID and entryCSN. There are plenty of pcache use cases where this will not be true.
Howard Chu wrote:
masarati@aero.polimi.it wrote:
hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
Modified Files: pcache.c 1.177 -> 1.178
Log Message: ITS#6251 framework for TTR. refresh not yet implemented.
At the moment the idea for implementing refresh is to refactor syncrepl_entry() so that we can reuse the bulk of it. (Mainly the code that generates an appropriate Modify request based on the difference between the local entry and the remote entry.)
Detecting renames will be trickier since the cache typically won't have any entryUUIDs. I think we'll simply have to treat it as a Delete / Add...
... which makes sense for a cache, all in all.
Or, as implementing this feature seems to move towards on-demand sync replication, we could always include entryUUID and entryCSN in the requested attributes, e.g. by implicitly adding them to the attrsets.
Yes, but that's only viable if the target server supports entryUUID and entryCSN. There are plenty of pcache use cases where this will not be true.
Other LDAP servers have similar attributes.
entryUUID: GUID on eDirectory, objectGUID on MS AD and ADAM.
Similar for entryCSN. (Can look up these if needed.)
How about making this configurable?
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
masarati@aero.polimi.it wrote:
hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
Modified Files: pcache.c 1.177 -> 1.178
Log Message: ITS#6251 framework for TTR. refresh not yet implemented.
At the moment the idea for implementing refresh is to refactor syncrepl_entry() so that we can reuse the bulk of it. (Mainly the code that generates an appropriate Modify request based on the difference between the local entry and the remote entry.)
Detecting renames will be trickier since the cache typically won't have any entryUUIDs. I think we'll simply have to treat it as a Delete / Add...
... which makes sense for a cache, all in all.
Or, as implementing this feature seems to move towards on-demand sync replication, we could always include entryUUID and entryCSN in the requested attributes, e.g. by implicitly adding them to the attrsets.
Yes, but that's only viable if the target server supports entryUUID and entryCSN. There are plenty of pcache use cases where this will not be true.
Other LDAP servers have similar attributes.
entryUUID: GUID on eDirectory, objectGUID on MS AD and ADAM.
Similar for entryCSN. (Can look up these if needed.)
How about making this configurable?
pcache has been working fine without explicit support of these so far, and they're not critical to the current work. I'm not opposed to someone adding these later, but I don't have time for them right now.
Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
masarati@aero.polimi.it wrote:
hyc@OpenLDAP.org wrote: Detecting renames will be trickier since the cache typically won't have any entryUUIDs. I think we'll simply have to treat it as a Delete / Add...
... which makes sense for a cache, all in all.
Or, as implementing this feature seems to move towards on-demand sync replication, we could always include entryUUID and entryCSN in the requested attributes, e.g. by implicitly adding them to the attrsets.
Yes, but that's only viable if the target server supports entryUUID and entryCSN. There are plenty of pcache use cases where this will not be true.
Other LDAP servers have similar attributes.
entryUUID: GUID on eDirectory, objectGUID on MS AD and ADAM.
Similar for entryCSN. (Can look up these if needed.)
How about making this configurable?
pcache has been working fine without explicit support of these so far, and they're not critical to the current work.
I agree it's not critical.
I'm not opposed to someone adding these later, but I don't have time for them right now.
It was just a suggestion.
Ciao, Michael.
pcache has been working fine without explicit support of these so far, and they're not critical to the current work. I'm not opposed to someone adding these later, but I don't have time for them right now.
Please, consider it food for thoughts.
p.
masarati@aero.polimi.it wrote:
pcache has been working fine without explicit support of these so far, and they're not critical to the current work. I'm not opposed to someone adding these later, but I don't have time for them right now.
Please, consider it food for thoughts.
Certainly. I think it would be more interesting to use them in the syncrepl code first, though. The syncrepl engine is intended to work with other mechanisms after all; we could start by fleshing out the retro-changelog consumer code. (At this point I think all that's needed is to omit the requirement of a syncrepl control on each response.)
-
Howard Chu -
masarati＠aero.polimi.it -
Michael Ströder