Matthew Swift a écrit :
and Entry should have at least an immutable DN (and facilities to
copy an entry with a new DN or ParentDN at factory level).
If the DN is immutable, entry's DN will be too.
I think Francois is stating that Entry should have a DN getter but no
setter. In other words the DN is set during construction and cannot be
changed afterwards. I personally think that this restriction is a bit
artificial.
You mean it will be a real PITA ;) Every ModDN operation applied to
entries will force us to duplicate the full entry. No way !
A similar artificial constraint could be imposed on the objectClass
attribute (i.e. don't allow the structural object class to be
changed). Whilst technically correct at the LDAP protocol level, I
don't think that these constraints should be imposed at the API level.
For example, imagine a GUI for creating a new user entry. The DN is
going to be constructed from (usually) the cn or uid attribute. The
user will want to type in the cn/uid in an entry box, but then may
realize that they made a typo and need to correct the cn/uid. We don't
want to prevent them from doing this?
No, certainly not ! Seriously, it would be too rigid, even on the client
side.
For attribute, the rationnal is that one replace attribute by a new
one most of the time, and it's much easier to deal with immutable
attribute - that's one of the aspect of UnboundId SDK that I prefer.
Inside the server, having immutable Attribute is not really a
problem. From the client POV, I'm not convinced...
I totally agree. Client apps are very different to the server.
Interestingly most of the pain we had with the immutable Attribute API
in the server was in client apps such as LDIF tools and unit tests
(most unit tests are like mini client apps).
Totally on the same page.
