directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Warren Rogers (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 02:29:00 GMT

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

Warren Rogers commented on DIRSERVER-2077:
------------------------------------------

I came across the original issue also with M24.

After some troubleshooting, and not being able to use this workaround, I finally found the
problem.

The *config.ldif* has the attribute *ads-baseDn* with the value of " " (space).

The config.ldif conversion works perfectly with the space, but if that space is removed so
that the attribute reads just *ads-baseDn:* the conversion fails.

So, how did the exported file have those spaces removed?  My IDE (JetBrains Idea) is set to
clean extra whitespace from files, for size and general cleanliness.  Thus, the working file
now fails with my new directory server vs the directory server I created via Apache Studio,
which I used to export the *config.ldif*.

So, I would say this is still a bug.  Values of attributes should be allowed non-space, or
no value.  Or, require non-value attributes be some other value, such as 'null'  If 'null'
is not allowable, then the reader should add the space during initialization.

> 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