Re: Still having trouble with saving BelongsToMany data

UPDATE

i worked with my form inputs and the Controller a bit, and i DO have functioning saves working again (for the next ten minutes until it breaks again). i'll describe what i had to do, and why i don't like it.

Form inputs:
Basically, i have to scrap the idea of the ORM carrying data to the pivot table. i have my main inputs all named according to their Listings column. For the data that will go to ListingsAttributes, i prefix the input with 'attributes.column':

<!-- 3 is the index position of the input group, 1 is the actual record ID -->
<input name="attributes[3][attribute_id]" value="1" type="checkbox">
<input name="attributes[3][value]" type="text">

In the Controller:

$listing = $this->Listings->newEntity();
if ($this->request->is('post')) {
    // Grab the 'attributes' data - arrays of attribute_id / value pairs
    $attributeData = $this->request->data['attributes'];
    // Can't leave the 'attributes' in the request data for the entity patch, Listings save fails.
    unset($this->request->data['attributes']);
    // NOTE: NO 'association' key. Just a single save action.
    $listing = $this->Listings->patchEntity($listing, $this->request->data);
    // Save the link records one-by-one
    foreach ($attributeData as $attrData) {
        $attribute = $this->Listings->Attributes->get($attrData['attribute_id']);
        $attribute->_joinData = new Entity(['value' => $attrData['value']]);
        $this->Listings->Attributes->link($listing, [$attribute]);
    }
}

Of course there's the redirect after everything succeeds & so on.

Why this is awful:

1. Absolutely NOT what's documented for this approach OR for the supposedly easier ['associated' => ['Attributes._joinData']] i was struggling with.
2. Cramming inputs into the form only to extract them to a separate data set, unset them from the original, then loop through them for individual save actions. This is not what i envisioned ORM sweetness to be.
3. Non-transactional - at any point, a save can fail and i get PART of the data, and can't roll back to make the user try the entire transaction over again. Instead, i'd have to have cleanup code in my add action to sweep up behind a failed save.
4. i suppose i could do it in a manually-set transaction, but that goes right back to defeating the purpose of the ORM.

Since there was someone on IRC also experiencing the same struggle i'm having, i'll hang out there a while to see if markstory comes back around to address it. It just baffles me that this particular data scenario does NOT work.

He even seemed to concede that the task we are trying to accomplish isn't directly accounted for in the test cases. One of the tests is for a Create/Update on both sides of the association, which i think is clear by now i'm NOT trying to do. The other test case he showed us retrieves an existing Entity and does an Update with a Create/Update on the other end and _joinData in between. When we explained we want to save only on ONE side & the pivot, and leave the other end untouched, he agreed the tests don't specifically account for that. So if i can catch him online, hopefully we can sort out whether it's something i'm still doing wrong, or the ORM, the Marshaler, or whatever.

Thanks again for the help. i'll follow up if i learn anything more.

On Friday, 13 March 2015 13:13:30 UTC-4, heavyKevy wrote:

I believe that is your answer you were looking for...
I missed it too.

Thanks Jose for pointing that one out.

--
Like Us on FaceBook https://www.facebook.com/CakePHP
Find us on Twitter http://twitter.com/CakePHP

---
You received this message because you are subscribed to the Google Groups "CakePHP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cake-php+unsubscribe@googlegroups.com.
To post to this group, send email to cake-php@googlegroups.com.
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/d/optout.