Here is a SQL query I've used for examining the group hierarchy. It is fixed to 5 levels since we don't have much nesting in our system.
select epg1.eperson_group_id as GID1, epg1.name as Name1, epg2.eperson_group_id as GID2, epg2.name as Name2, epg3.eperson_group_id as GID3, epg3.name as Name3, epg4.eperson_group_id as GID4, epg4.name as Name4, epg5.eperson_group_id as GID5, epg5.name as Name5 from epersongroup epg1 left join group2group g2g1 on g2g1.parent_id=epg1.uuid left join epersongroup epg2 on epg2.uuid=g2g1.child_id left join group2group g2g2 on g2g2.parent_id=epg2.uuid left join epersongroup epg3 on epg3.uuid=g2g2.child_id left join group2group g2g3 on g2g3.parent_id=epg3.uuid left join epersongroup epg4 on epg4.uuid=g2g3.child_id left join group2group g2g4 on g2g4.parent_id=epg4.uuid left join epersongroup epg5 on epg5.uuid=g2g4.child_id order by Name1,Name2,Name3,Name4,Name5 -- Sean On 2020-06-19, 9:48 AM, "Mark H. Wood,UL 0115A,+1 317 274 0749, on behalf of Mark H. Wood" <[email protected] on behalf of [email protected]> wrote: The seemingly endless recursion (which caused the stack overflow) makes me think that there may be a circular group membership somewhere. Group A contains group B contains group A would be a simple example. The only way I've thought of to look for such a problem is to inspect the group2group database table. The content of that table should represent a collection of directed acyclic graphs. If one of those graphs is cyclic, GroupServiceImpl.getChildren will never terminate and will eventually fill the stack. I don't have a simple, quick way to find such a cycle, but I found a few references that will probably tell you more than you ever wanted to know about the subject, with suggestions for practical solutions. https://stackoverflow.com/questions/261573/best-algorithm-for-detecting-cycles-in-a-directed-graph https://www.geeksforgeeks.org/detect-cycle-in-a-graph/ https://en.wikipedia.org/wiki/Cycle_(graph_theory) I'd read the one at StackOverflow first. Remember that the table probably contains *more than one graph*. The 'epersongroup' table contains all of the groups and may be helpful for inspecting the whole collection of graphs. There's another approach: add some code to limit the depth of getChildren, throwing an exception when the limit is hit. Catching, logging and then re-throwing the exception in getChildren ought to show you the problematic path. This would be similar to the depth-first search for a cycle suggested in the references above. I don't know which way would be better for you. We probably ought to have such an (adjustable) depth limit in getChildren anyway. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/20200619144824.GB14311%40IUPUI.Edu. -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/35D16822-A01C-4F13-B7B2-042D4E0AD169%40umanitoba.ca.
