[
https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16138047#comment-16138047
]
Emmanuel Lecharny edited comment on DIRSERVER-2077 at 8/23/17 8:17 AM:
-----------------------------------------------------------------------
I concur.
The LDIF spec ([http://www.faqs.org/rfcs/rfc2849.html]) is pretty clear :
{noformat}
ldif-file = ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" ( FILL 0*1(SAFE-STRING) / ":" FILL
(BASE64-STRING) / "<" FILL url)
FILL = *SPACE
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B /
%x3D-7F
{noformat}
Which means something like {{ads-baseDn:}} is for a null value stored in
{{ads-baseDn}} (which is legit : {{rootDSE}}), for instance,
{{ads-baseDN:<space>}} (with an ending space: JIRA formater does not work when
using a ' ' beofre a '}') is for the exact same thing as the leading space will
be taken for the {{FILL}} part of the LDIF grammar. So basically, they are
encoding for the same value, and if the ldif parser does not see them as the
same value, then it's a big bug.
was (Author: elecharny):
I concur.
The LDIF spec ([http://www.faqs.org/rfcs/rfc2849.html]) is pretty clear :
{noformat}
ldif-file = ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" ( FILL 0*1(SAFE-STRING) / ":" FILL
(BASE64-STRING) / "<" FILL url)
FILL = *SPACE
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B /
%x3D-7F
{noformat}
Which means something like {{ads-baseDn:}} is for a null value stored in
{{ads-baseDn}} (which is legit : {{rootDSE}}), for instance, {{ads-baseDN\: }}
(with an ending space) is for the exact same thing as the leading space will be
taken for the {{FILL}} part of the LDIF grammar. So basically, they are
encoding for the same value, and if the ldif parser does not see them as the
same value, then it's a big bug.
> Provide tools to migrate the config or the data between releases
> ----------------------------------------------------------------
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheDS
> Issue Type: Task
> Affects Versions: 2.0.0-M20
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Fix For: 2.0.0-M24
>
>
> We have been lazy in the past, by not provided tools to migrate from one
> version to the other, simply because they were milestones.
> There are three things we need to migrate :
> - configuration
> - schemas
> - data
> for each of those data, we have to provide a tool that helps the migration
> from one version to the next one.
> Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should
> migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
