Grouper Users - Open Discussion List

[Peter DiCamillo <>]

I did additional testing and found that if I started with an empty 
registry and only created groups using XML imports there were no missing 
group memberships.  I also verified that group UUIDs were preserved.

What confused me is that the -name option allows you to dump and then 
restore just a subtree of the registry.  That implied to me that I could 
use XML export and import to recreate one subtree of a registry, and 
recreate other subtrees using different methods, such as manually or 
using local provisioning programs.  I wasn't aware of the dependence on 
group UUIDs being preserved.  Our local provisioning program always 
reference groups by ID path, not UUIDs, so I'm not used to thinking of 
the UUIDs being significant.

Peter

Tom Zeller wrote:
> Although not an exhaustive test, I was not able to reproduce this
> issue when I imported into a new 1.6 instance a 1.3 xml export which
> was created using -name <stem immediately under root>. Group members
> of groups were restored correctly, at least for those I checked.
>
> If the import was to a blank 1.6 database, it would be interesting to
> compare the id in the grouper database to the id in the exported xml
> of a group which is a member of another group whose memberships were
> not imported correctly.
>
> On Wed, Aug 25, 2010 at 3:15 PM, Peter DiCamillo
> <>
>  wrote:
> > I'm in the process of doing an upgrade from Grouper 1.3 to Grouper 1.6.1
> > using the first method.  I dumped some groups in 1.3.1 and restored them in
> > 1.6.1 using -xmlimportold.  I dumped a stem immediately under the root using
> > -name, and no other options.  I didn't use any options on the import
> > command.
> >
> > I found that group members of groups were not being restored.  I checked the
> > dump and it looks fine, with correct entries for group members of groups.
> >  The groups to be added as members already existed, but the log showed them
> > not being found.  The problem seems to be in the restore program,
> > XmlImporter.java, and this change fixed it for me:
> >
> >  426c426,431
> >  <     return this._getSubjectById(id, type);
> >  ---
> >  >     if (type.equals("group")) {
> >  >       return this._getSubjectByIdentifier(idfr, type);
> >  >     }
> >  >     else {
> >  >       return this._getSubjectById(id, type);
> >  >     }
> >
> > I wouldn't expect the restored group to have the same id as the original
> > group (unlike people, who do have the same id), so I'm wondering how this
> > was intended to work.
> >
> > Peter
> >
> > Chris Hyzer wrote:
> > > There are two upgrade methods:
> > >
> > > 1. Export XML, then import into the version you would like (in 1.6, the
> > > xml format changed, but you can still import the old with
> > > ./gsh.sh -xmlimportold GrouperSystem export.xml
> > >
> > > However, Im not sure all the lastUpdated dates and minor stuff like that
> > > is maintained.   Also not sure about group descriptions (this was fixed in
> > > some version, not sure which).
> > >
> > > 2. Do all the individual upgrade steps.
> > >
> > > I went from 1.4 to 1.6 and did the individual steps.  It was time
> > > consuming though.  If you want to give #1 a try, go for it, and check the
> > > data afterwards...
> > >
> > > Thanks,
> > > Chris
> > >
> > > -----Original Message-----
> > > From: 
> > >
> > > [mailto:]
> > >  On Behalf Of Scott Koranda
> > > Sent: Thursday, August 19, 2010 3:55 PM
> > > To: 
> > >
> > > Subject: [grouper-users] upgrading from 1.4.2 to 1.6.1
> > >
> > > Hi,
> > >
> > > Is it possible to upgrade from Grouper 1.4.2 to 1.6.1 without
> > > stopping at 1.5.x?
> > >
> > > What would be the best strategy?
> > >
> > > (We are using MySQL as the backend)
> > >
> > > Thanks,
> > >
> > > Scott