Grouper Users - Open Discussion List

[Shilen Patel <>]

OK great.

The only thing that should be inserting to those table is that daemon job.  
So I don’t know how you got duplicates in there.  And even if you had 
multiple instances of the job running at the same time somehow, the 
transactions in the database should have still prevented the duplicates.  
What database are you using?  If you look at your loader logs 
(grouper_loader_log) during the time when that member was created, do you see 
any signs that multiple instances of CHANGE_LOG_changeLogTempToChangeLog were 
running at the same time?

Thanks!

- Shilen

On 1/18/19, 3:51 PM, "Scott Koranda" 
<>
 wrote:

    Hi,
    
    > I wonder if you have more duplicates.
    
    Running
    
    new 
edu.internet2.middleware.grouper.misc.SyncPITTables().processAllDuplicates()
    
    showed
    
    Hib3PITGroupSetDAO: Searching for point in time duplicates
    Found 29 entries that have duplicates in point in time.
    
    I then wrote some SQL to query for the rows with the correct
    sourceId(s), find the id(s), and delete the rows for the
    grouper_pit_group_set table. The deletions worked where the row did not
    have a foreign key and failed when there was a foreign key. Each
    sourceId had 2 and not more than 2 entries.
    
    After that I ran
    
    new 
edu.internet2.middleware.grouper.misc.SyncPITTables().processAllDuplicates()
    
    again and this time it processed updated without any errors.
    
    I was then able to run
    
    loaderRunOneJob("CHANGE_LOG_changeLogTempToChangeLog");
    
    Can you provide any insights into how the duplicates came to be in the
    PIT tables?
    
    This Grouper deployment is not especially unique or large. It is
    manipulated through Grouper WS calls and occasionally through the UI.
    The WS calls simply add or remove subjects from groups and occasionally
    create groups.  There are no loader jobs other than running the PSPNG.
    
    Thanks,
    
    Scott K