provide an ids_writer

[flyingzumwalt]

See the ids_writer branch for tests that outline how this should work

    describe "#ids_writer" do
      let(:image) { Image.new }
      context "with saved members" do
        before do
          image.generic_file_ids = [generic_file1.id, generic_file2.id]
          image.save
        end

        subject { image.reload.generic_file_ids }
        it { is_expected.to eq [generic_file1.id, generic_file2.id] }

        it 'can rearrange members' do
          image.generic_file_ids = [generic_file2.id, generic_file1.id]
          image.reload
          expect(image.generic_file_ids).to eq [generic_file2.id, generic_file1.id]
          expect(image.generic_files).to eq [generic_file2, generic_file1]
        end
        it 'can wipe out members' do
          image.generic_file_ids = []
          image.reload
          expect(image.generic_file_ids).to eq []
          expect(image.generic_files).to eq []
        end
      end
    end

[jcoyne]

It's not clear to me how this is going to put generic_file_ids in order since generic_files is a subset of the members list. It could be interleaved with generic_works too. See https://github.com/projecthydra-labs/hydra-works/blob/master/lib/hydra/works/models/concerns/generic_work_behavior.rb#L23-L24

[flyingzumwalt]

Your comment doesn't apply to this ticket. Did you mean to comment on the
related issue in hydra-works? Even if we define a different aggregation to
track these members, we will still need to be able to update the members
list based on an array of ids without loading all of the member objects.

On Tuesday, September 8, 2015, Justin Coyne notifications@github.com
wrote:

It's not clear to me how this is going to put generic_file_ids in order
since generic_files is a subset of the members list. It could be
interleaved with generic_works too. See
https://github.com/projecthydra-labs/hydra-works/blob/master/lib/hydra/works/models/concerns/generic_work_behavior.rb#L23-L24

—
Reply to this email directly or view it on GitHub
#71 (comment)
.

[tpendragon]

@flyingzumwalt I'm not sure you want to do that. In fact, I'm suddenly wondering what's happening to the proxy nodes when you set actual objects to the filter associations - it may be we don't want setters for #generic_files at all.

#members is a list of all members with a set of proxy nodes which auto-link themselves up in a doubly linked list. My concern is that you'd get a list of GenericFiles from #generic_files, set #generic_files= to a new reordering of them, and then a "work" in the middle (which you couldn't see before because you filtered it out in display) would get orphaned from the ordered chain.

[flyingzumwalt]

I think you're both getting confused by the name of this aggregation. In
this test, Image aggregates generic_files. generic_files is a regular
aggregation, not a filtered aggregation, meaning that in this test
image.generic_files is equivalent to pcdm_object.members, not
hydra_works_object.generic_files

On Wednesday, September 9, 2015, Trey Terrell notifications@github.com
wrote:

@flyingzumwalt https://github.com/flyingzumwalt I'm not sure you want
to do that. In fact, I'm suddenly wondering what's happening to the proxy
nodes when you set actual objects to the filter associations - it may be we
don't want setters for #generic_files at all.

#members is a list of all members with a set of proxy nodes which
auto-link themselves up in a doubly linked list. My concern is that you'd
get a list of GenericFiles from #generic_files, set #generic_files= to a
new reordering of them, and then a "work" in the middle (which you couldn't
see before because you filtered it out in display) would get orphaned from
the ordered chain.

—
Reply to this email directly or view it on GitHub
#71 (comment)
.