Thanks @mseaton, I wasn't aware of that. We are now talking about the following method, right?
The implementation seems to load items in each child set separately from the database and just append all the results in a list. This is quite inefficient but I'm sure it can be fast enough in practice if there are not too many sets inside the root set. So far I don't have any hard numbers on how many items a MetadataSet might contain but earlier @raff commented on my earlier design proposal:
We must be prepared that some MetadataSets may have hundreds of members and require paging. The initial design lets you properly implement fetching a subset of members and paging in a service method. In your proposal we must rely on Hibernate lazy loading and API users careful handling, who should not be calling getMembers().size() for example.
getConceptsByConceptSet does not support paging and using its design to do paging would be basically as inefficient as just loading the whole list of descendant items but returning just a subset (one page) of them. Also,
getConceptsByConceptSet does not sort the items but of course it could be modified to do sorting in memory.
If the Concept/ConceptSet approach is deemed acceptable then I can implement that easily. Even the MetadataSet/MetadataSetMember approach I proposed earlier will work if we just allow MetadataSetMember to reference either a MetadataTermMapping or MetadataSet. No problem there.
However, I would be more comfortable if we could take a step back and first think about the requirements of clients. How big are the sets and how many nested sets might they have? How would a client iterate the hierachy of sets? What are all the different use cases? Is paging a requirement for the actual utilization of MetadataSets or just for the management of MetadataSets? Does ordering matter and, if it does, in which use cases?