directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
Date Wed, 23 Aug 2017 08:10:00 GMT

    [ https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16138047#comment-16138047
] 

Emmanuel Lecharny commented on DIRSERVER-2077:
----------------------------------------------

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)

Mime
View raw message