[ 
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:10 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: }} 
(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.


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)

Reply via email to