Grouper Users - Open Discussion List

[Chris Hyzer <>]

Btw, we arent talking two uuid's which were independently generated in to 
different environments and happen to be the same, since that is impossible*, 
but we are talking about a group that was migrated or copied before that has 
the same uuid for that reason, then you want to import again and change the 
name to make a copy...

Thanks,
Chris

* by impossible, I mean it is very very very very very unlikely...


-----Original Message-----
From: Dominique Petitpierre 
[mailto:]
 
Sent: Wednesday, March 13, 2013 10:40 PM
To: Chris Hyzer
Cc: 

Subject: Re: [grouper-users] xmlExport: how to export groups without any uuid 
reference?

Hello,

thanks for your reply:

On 03/13/2013 04:22 PM, Chris Hyzer wrote:
> At a high level, what would you like to do?  Export 
> groups/members/privileges from certain stems?  Anything else?

Here are a few situations where I used the old style export/import
(before it was labeled Legacy in the wiki :-)
cf. 
https://spaces.internet2.edu/display/Grouper/GrouperShell+%28gsh%29#GrouperShell%28gsh%29-XMLexportlegacy):

- Partial copy from one instance of Grouper to another.  For example,
   after a set of stems and groups have been perfected on the test
   instance, copy these to the production instance with or without
   person members.  This is because recreating the stems and groups
   manually in the Grouper UI is tedious and error prone.

- Rename and reorganize groups within an instance. As you know naming
   and organizing stems and groups is not easy and is subject to
   iterations. Renaming or reorganizing in the Grouper UI can be
   tedious and error prone while editing a xml file (manually or not)
   can be convenient.

- Reporting: extract various informations from the exported file for
   the purpose of checking (e.g. diff), documenting or doing statistics.

This is not really provisioning because such operations are done only once.

For creating stems and groups from scratch, I use scripts that convert
a group list to a gsh script. Generating an xml export file is not
really convenient for that purpose.


> Maybe there is a better way than the export/import tool which should work 
> well for full registries, but obviously has issues with partial 
> exports/imports...

What tools and methods would you suggest?

...
>>>   Note: uuid's will only be used on new objects...
>>
>> - What defines a new object when importing? the path? the uuid? The
>>    pair path+uuid?
>> - Any risk of uuid collisions between different instances of Grouper?
>>
>> In other words
>> - is there a risk to corrupt the DB by importing an xml file containing
>>    an unhappy (but locally correct) combination of elements?
>
> I don’t think you can corrupt it.  If there is a name already in the DB 
> with a different UUID, then it will not change the UUID.  If there is no 
> name/uuid in the DB, then it will use the exported one.

Just to be sure, with gsh -xmlimport,
- is it OK to import an object that has a new name (e.g. it has been
   edited by hand in the exported xml file) but has the same UUID as an
   existing object?


...
>> 1) When exporting a very small stem (test:t containing test:t:g1,
>> test:t:g2) the output xml file contains the two group objects but
>> even though the groups g1 and g2 have only one person member each, it
>> seems that all the person members of all the groups are included in the 
>> file
>> (<XmlExportMember>).  Idem for the audit part: it seems all the audit
>> data is exported.
>
> Yes, all member records are exported, which are not memberships, so it 
> should not be a problem...

Just that it can take ages to export and then to import even a small
stem if the subject list is large.  In the example case, export is
done in a few seconds with the old style xmlexport and takes half an
hour with the new style xmlexport.


Best regards,
Dominique
--
Mr Dominique Petitpierre, user=Dominique.Petitpierre domain=unige.ch
IT Division, University of Geneva, Switzerland