Open elrayle opened 5 years ago
# Setup objects
parent_work1 = GenericWork.new(id: 'wk1')
parent_work2 = GenericWork.new(id: 'wk2')
child_work = GenericWork.new(id: 'wk3')
# Setup relationships
parent_work1.ordered_members = [child_work]
parent_work2.ordered_members = [child_work]
child_work.save
parent_work1.save
parent_work2.save
# test relationships
parent_work1.member_ids # expected: [wk3] actual: [wk3]
parent_work2.member_ids # expected: [wk3] actual: [wk3]
parent_work1.ordered_member_ids # expected: [wk3] actual: [wk3]
parent_work2.ordered_member_ids # expected: [wk3] actual: [wk3]
child_work.in_work_ids # expected: [] actual: [wk1, wk2]
child_work.member_of_work_ids # expected: [wk1, wk2] actual: [wk1, wk2]
child_work.parent_work_ids # expected: [wk1, wk2] actual: [wk1, wk2, wk1, wk2]
Implementation path of in_work_ids
...
in_work_ids
calls in_works
ordered_by
"{!join from=proxy_in_ssi to=id}ordered_targets_ssim:#{id}"
As written, in_work_ids
seems to be using solr to find ordered members. I expected this method to use the members relationship to find all parents and then limit the results to only work
parents.
Implementation path of member_of_work_ids
...
member_of_work_ids
calls member_of_works
in_objects
member_of
defined in PCDM by members
ordered_aggregation relationshipI do expect this method to use the member_of
relationship to find all parents for a work. I'm just not sure why it is defined. I wouldn't expect ordered_aggregation
relationship to define this reverse relationship method.
Ran same relationship checks when relationship was setup using members
instead of ordered_members
.
parent_work1.member_ids # expected: [wk3] actual: [wk3]
parent_work2.member_ids # expected: [wk3] actual: [wk3]
parent_work1.ordered_member_ids # expected: [] actual: []
parent_work2.ordered_member_ids # expected: [] actual: []
child_work.in_work_ids # expected: [] actual: []
child_work.member_of_work_ids # expected: [wk1, wk2] actual: [wk1, wk2]
child_work.parent_work_ids # expected: [wk1, wk2] actual: [wk1, wk2]
Relationship Expectations
member_of_collection
relationshipmembers
relationshipExpected method behaviors:
in_works
would return parents defined by the members
relationship which tracks membership by the parent knowing about the childmember_of_works
would return parents defined by a member_of
relationship which tracks membership by the child knowing about its parentsmembers
relationship to be defined by using AF ordered_aggregation
member_of
relationship to be defined by using AF indirectly_contains
Summary of Actual method behaviors:
parent_works = in_works + member_of_works
in_works
returns the list of ordered members filtered to just worksmember_of_works
uses reflection method member_of
defined through ordered_aggregation
relationship members
and filters to just works (Not confident this is exactly right because I would not expect ordered_aggregation
to defined member_of
)As written, the methods are behaving as expected. But I don't believe this is what was originally intended.
Descriptive summary
Adding a child work to a parent work using ordered members causes the child to respond with parent works using both in_work_ids and member_of_work_ids, resulting in the parent work being listed twice.
Rationale
In the list of parent_works, the parents should not repeat.
Expected behavior
Actual behavior
See PR #360 which includes a test that fails because of this bug.
Steps to reproduce the behavior
Use test provided in PR #360 to debug.
Expect
parent_works
to returnparent_work1
andparent_work2
, but you get the two parent works in the list twice.Related Work
PR https://github.com/samvera/hyrax/pull/3697 - Orders members when converting to AF objects