Hi,
This is related to my earlier question about creating Realms based on
dynamic VO's (organized as o= entities in LDAP).
I'm trying to get FULL RECONCILIATION working, which succeeds for the first
time, but results in unique "u_realm_name" constraint violations on second
attempt, even though I have set matching rule to ignore. So, it seems
syncope has no way of understand what realms are allready provisioned and
this is intended as a one-time provision action?
The setup uses the __ACCOUNT__ objectclass, because that's the only way I
got the search code to apply my object filter (I don't want objects of
objectClass=dcObject). Mapping to organization only doesn't apply this
filter.
In the mapping, I assign internal 'name' to external 'o' (Remote Key,
purpose: <-) and use Object link 'o='+name+',dc=scz,dc=vnet'.
I set the resource Account objectClass to organization and LDAP Filter for
Retrieving Accounts to (!(objectClass=dcObject)). I can see this working
correctly when I explore the resource.
First time pull results in these succeful actions:
Realms [created/failures]: 3/0 [updated/failures]: 0/0 [deleted/failures]:
0/0 [no operation/ignored]: 0/0
Realms created in the root realm:
CREATE SUCCESS (key/name): 3a3370df-3aa2-4787-b370-df3aa2278786///Foobar
CREATE SUCCESS (key/name): 38d90785-ab9c-4fc8-9907-85ab9c2fc8e4///Foobar2
CREATE SUCCESS (key/name): b3c86117-400b-457d-8861-17400bf57d5d///Foobar3
But all succesive attempts result in these exceptions in the
core-connid.log (abbreviated for readability):
org.apache.openjpa.persistence.EntityExistsException: The transaction has
been rolled back. See the nested exceptions for details on the errors that
occurred.
Caused by: org.apache.openjpa.persistence.EntityExistsException: ERROR:
duplicate key value violates unique constraint "u_realm_name"
Detail: Key (name, parent_id)=(Foobar,
ea696a4f-e77a-4ef1-be67-8f8093bc8686) already exists. {prepstmnt 220401755
INSERT INTO Realm (id, name, ACCOUNTPOLICY_ID, PARENT_ID,
PASSWORDPOLICY_ID) VALUES (?, ?, ?, ?, ?)} [code=0, state=23505]
If I set matching policy to update, this should never result in an INSERT,
so it's clear there is no match and the provisioner tries to "provision".
Best regards,
Martin
--
If 'but' was any useful, it would be a logic operator
