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 https://github.com/projecthydra-labs/activefedora-aggregation/issues/71#issuecomment-138745820 .

[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 https://github.com/projecthydra-labs/activefedora-aggregation/issues/71#issuecomment-138944311 .