Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fileset #in_works method always returns [] #301

Open
elrayle opened this issue Jun 13, 2016 · 5 comments
Open

fileset #in_works method always returns [] #301

elrayle opened this issue Jun 13, 2016 · 5 comments
Labels

Comments

@elrayle
Copy link
Contributor

elrayle commented Jun 13, 2016

Description

When a fileset is in a work, calling method #in_works does not return the work.

Expected Results

in_works should return the work in an array

Actual Results

in_works returns an empty array

To reproduce

w1 = Hydra::Works::Work.new(id: 'w-1')
fs1 = Hydra::Works::FileSet.new(id: 'fs-1')
w1.members << fs1
w1.save

fs1.in_works  # => []
fs1.save
fs1.in_works  # => []

NOTE: If you create a collection and add w1 as a member, w1.in_collections will return an empty array until the collection is saved. In the code to reproduce, w1 is saved after putting fs1 into its member list.

@elrayle elrayle added the bug label Jun 13, 2016
@awead
Copy link
Contributor

awead commented Jun 13, 2016

calling .ordered_members instead of .members fixes this. I'm not sure what the expectation is of the members method, but the tests indicated that ordered_members is the method to use:
https://github.com/projecthydra/hydra-works/blob/master/spec/hydra/works/models/file_set_spec.rb#L40-46

@elrayle
Copy link
Contributor Author

elrayle commented Jun 14, 2016

Is .ordered_members the preferred method that should be encouraged over .members?

There are inconsistencies in the functioning of the in_* methods.

Examples assume
c1, c2 are collections
w1, w2 are works
fs1 is fileset
c1 and w1 are empty at the start of each set of statements

w1.members << fs1
w1.save
fs1.in_works   # => []

w1.ordered_members << fs1
w1.save
fs1.in_works   # =>    #<Work id: "w1" ... >

w1.members << w2
w1.save
w2.in_works   # => []

w1.ordered_members << w2
w1.save
w2.in_works   # =>   #<Work id: "w1" ... >

c1.members << c2
c1.save
c2.in_collections   # =>    #<Collection id: "c1" ... >

c1.ordered_members << c2
c1.save
c2.in_collections   # =>   #<Collection id: "c1" ... >

Why wouldn't the in_works and in_collections methods return all containing works and collections, respectively, whether the contained item was added with .members or .orderedmembers?

I would expect...

w1.members << w3
w2.ordered_members << w3
w3.in_works    # => #<Work id: "w1" ... >, #<Work id: "w2" ... >

@awead
Copy link
Contributor

awead commented Jun 14, 2016

I would be in favor of deprecating the members method altogether since all members are ordered by default.

@tpendragon
Copy link
Contributor

I would be in favor of deprecating the members method altogether since all members are ordered by default.

Not for collections. Ordering's moderately expensive, so when it's not needed it's important to have that option.

#in_works and #in_collections should probably work off members instead of ordered_members.

@elrayle
Copy link
Contributor Author

elrayle commented Jun 14, 2016

It makes sense for #in_works and #in_collections to use members instead of ordered_members. When going from the contained to the containing items, order is not important.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants