Feature #80
Force LSC to apply modifications if modrdn is false
| Status: | Closed | Start: | 15/06/2009 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assigned to: | Jonathan Clarke | % Done: | 100% |
|
| Category: | Core | |||
| Target version: | 1.1.0 |
Description
Hello,
I use a connector in "update-only" mode. So I set to false create/delete/modrdn conditions.
I do not use "dn" rule because I cannot set this rule (I don't know how the destination entries will be named). I just want to update an attribute in the destination entry (I know how to mach source entry and destination entry with a filter).
LSC see that my destination entry DN is not correct, so it tries to make a modrdn. My modrdn is false so it does nothing. But it does not do the update! Indeed, LSC is programmed to skip update i modrdn is required. But if modrdn condition is false, update should be made.
Are you agree?
Associated revisions
Fixes #80. Ignore MODRDNs if DN is explicitly set to empty string.
History
Updated by Clément Oudot about 1 year ago
I propose this patch:
Index: BeanComparator.java
===================================================================
--- BeanComparator.java (revision 251)
+++ BeanComparator.java (working copy)
@@ -106,6 +106,7 @@
return JndiModificationType.ADD_ENTRY;
} else { /* srcBean != null && destBean != null */
if (itmBean.getDistinguishName() == null
+ || ((Boolean)syncOptions.getModrdnCondition().equalsIgnoreCase("false"))
|| destBean.getDistinguishName().compareToIgnoreCase(itmBean.getDistinguishName()) == 0) {
return JndiModificationType.MODIFY_ENTRY;
} else {
It's ugly but seems to work.
Your opinion on this?
Updated by Jonathan Clarke about 1 year ago
This should indeed work (although you don't need the cast to (Boolean)).
However, it doesn't take into account the case where the modrdn condition is something more complex that needs evaluating, and ends up being false. We really should fully interpret the contents of the condition here, to be consistent.
Updated by Clément Oudot about 1 year ago
Jonathan Clarke wrote:
This should indeed work (although you don't need the cast to (Boolean)).
However, it doesn't take into account the case where the modrdn condition is something more complex that needs evaluating, and ends up being false. We really should fully interpret the contents of the condition here, to be consitent.
Hello,
I have a suggestion: we can test the 'dn' rule. If this rule is empty, this mean that we do not want to manage DN. In this case, we never check modrdn and go direct in update.
What do you think?
Updated by Jonathan Clarke about 1 year ago
- Category set to Core
How about a convention on the DN? Let's say if the source DN is "" (the empty string), then don't consider MODRDN. This could easily be done by setting:
lsc.tasks.TASKNAME.dn = ""
And implemented with this patch:
Index: src/main/java/org/lsc/beans/BeanComparator.java
===================================================================
--- src/main/java/org/lsc/beans/BeanComparator.java (révision 252)
+++ src/main/java/org/lsc/beans/BeanComparator.java (copie de travail)
@@ -110,6 +110,7 @@
return JndiModificationType.ADD_ENTRY;
} else { /* srcBean != null && destBean != null */
if (itmBean.getDistinguishName() == null
+ || itmBean.getDistinguishName().length() == 0
|| destBean.getDistinguishName().compareToIgnoreCase(itmBean.getDistinguishName()) == 0) {
return JndiModificationType.MODIFY_ENTRY;
} else {
Would this suit your needs? Does it seem coherant with everything else?
Updated by Clément Oudot about 1 year ago
Hello,
I tested your patch, and it works! Can you apply it to the trunk?
Thanks,
Clément.
Updated by Jonathan Clarke about 1 year ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset r254.
Updated by Jonathan Clarke about 1 year ago
- Assigned to set to Jonathan Clarke
- Target version set to 1.1.0
I have applied this, and updated the doc. See http://lsc-project.org/wiki/documentation/configuration/task#the_dn.
Updated by Clément Oudot about 1 year ago
Jonathan Clarke wrote:
I have applied this, and updated the doc. See http://lsc-project.org/wiki/documentation/configuration/task#the_dn.
Ok for me. I think you can close this issue.
Thanks a lot,
Clément.
Updated by Jonathan Clarke about 1 year ago
- Status changed from Feedback to Closed