Appending values when systemOfRecord is DESTINATION

Hmm, I have been trying the prepareRow() option but on the updating class that adds the EPS files and getting nowhere. This is probably why.

I will look into doing the override. Actually right before reading this reply I had already come to the conclusion that I would have to either override something in DestinationNode or write my own version of it entirely. This just seals the deal. Its taking me awhile to figure this stuff out because I am trying to understand how the code is working before I start doing things.

Actually in looking at it further, since the import function calls "$this->prepare($node, $row);" before saving the node I think I might be able to modify the node itself here if I invoke passing by reference in my function declaration.

But there is still another problem I see. Isn't the file field object (and subsequent file table population and file transfer) done before we get to this point? If it is then I will need a way to do that again from this point.

Ok, so I have been looking this over and that invoke will change it at the entity level, not the node level. So my first question is, is that at a deeper level than it needs to be for this to work or can it be done at the node level? The next question is where would I declare my prepare to make this happen? It doesn't look like preparing it at my setup class would work for the entity level and I am having trouble determining at what does extend the correct class to handle that.

It looks like to use that prepare statement I would have to extend the MigrateFieldsEntityHandler class or create a duplicate sibling class that can handle multiple file inputs. A more permanent solution would be to get it to allow multiple mappings to the same field by modifying addFieldMappings() in migration.inc. That bit is rather simple and could even be done at the level of the developers code that extends the "Migration" class. Below is what I am thinking of for that:

<?php
  protected function addFieldMapping($destination_field, $source_field = NULL) {
    $mapping = new MigrateFieldMapping($destination_field, $source_field);

    //If a mapping already exists then lets just add another one
    if (!is_null($destination_field) && isset($this->fieldMappings[$destination_field])) {
      $this->fieldMappings[$destination_field][] = $mapping;
    }
    else if (is_null($destination_field)) {
      $this->fieldMappings[] = $mapping;
    }
    else {
      $this->fieldMappings[$destination_field] = $mapping;
    }

    return $mapping;
  }
?>

Though in order for that to work any code that loads the results of those mappings would have to be able to handle the multiple mappings as well. I haven't traced any of those just yet. But that would be crucial for a permanent addition of this feature. After that it just needs to ensure that any entity or node modification calls can handle the multiple values as well when dealing with it prior to saving. I have been considering the need for a flag in the migration declaration that states that this migration will allow multiple values in fields.

I am still pondering over all of this.

Another question that has crossed my mind is that in the class "MigrateFieldsEntityHandler" in fields.inc the prepare function receives the $row object/array but doesn't do anything with it. If your going to have hooks that you invoke for a field then doesn't it make sense to pass in the row data in case it is needed? Or am I missing something?

The values the prepares do receive seem to be the information about the structure of the node entity field and not anything from the actual source or destination. So I am having trouble following where the row data is coming into the prepare function that is being invoked.

By the way a lot of this is my way to of speaking out loud to myself. Sometimes I just find it easier to work through things this way.

Ok, so I have given it some thought and here is an approach for appending files to a node on node update. We add a parameter to the migration called "multiValueFields" that will be an array of the fields in which you would like to allow multiple values for. Then, as long as the field is an array, you append the new values on it.

Essentially this only works for translatable fields such as files, images, the body, etc. But then it doesn't really make sense to append together ints or bools. I added in some code for strings, but it may need to be considered that we need to determine if we are appending or pre-pending to the string. Also we need to consider any separators (commas, spaces, pipes, poems, whatever). So the string thing needs a bit of hashing out.

So my idea for patching the migrate module would be two-fold. First for creating a new node (or whatever entity type we are using). This would require allowing for duplicate mappings and checking to make sure the field supports duplicate values.

The second would be to path updating nodes (and other types) and letting the developer specify which fields get updated. This would also have to allow for multiple mappings at some point. But if the first step is already working then you can just use that stuff.

In the mean time I have attached a file that contains the new node destination class. It extends upon the original instead of overwriting it. So it can allow for multiple ways of approaching this.

Yeah, I probably should have done that instead. Here is that patch file.

The variable "$migration->multiValueFields" isset check could be eliminated if we set the property by default in the class as an empty array. We could even eliminate the "is_array" check if we use getters and setters for it to control the data integrity.