Tuesday, March 3, 2015

Re: Still having trouble with saving BelongsToMany data

José
i appreciate your response. Please forgive my frustration, i'm trying to learn what i'm doing wrong (and i do still believe i'm doing something wrong, but can't figure out WHAT). Your comments make sense, and i was originally working under those assumptions. However, the original approach didn't work. i followed the documentation at
http://book.cakephp.org/3.0/en/orm/saving-data.html#saving-additional-data-to-the-joint-table
http://book.cakephp.org/3.0/en/views/helpers/form.html#associated-form-inputs
which are what gave me inputs and POST data matching exactly what the documentation describes. But when feeding the POST into patchEntity, the association data disappears.

i re-baked my models and the Controller, dealing almost entirely with the automatic code (changing only what i needed for views/layouts - nothing affecting data). It didn't work. The furthest i could get with that was the Listing record, but the Listing entity never had the associated Attribute data. The first time anything DID save to ListingsAttributes was with Kevin's changes.

The only discrepancy i see is the documentation calling
$this->Students->newEntity($data, // POST data
   
['associated' => ['Courses._joinData']]);
while your comment below used
$this->Posts->patchEntity($post, $this->request->data,
                         
['Tags._joinData']);
Leaving aside the object differences, is that options array correct?

i was using newEntity to create it directly from POST, as the documentation does. The re-baked Controller switched it to patchEntity & Kevin's changes did the same, so i went that way.

i've been calling
$this->Listings->patchEntity($listing, $this->request->data,
                             
['associated' => ['Attributes._joinData']]);

i've tried to be very clear about what i was originally doing, and Kevin had the same problem: no associated record saved. He was very helpful, offering clear instructions for what he changed to get it to work, which is where i am now. All the points i listed are from changes he had to make to get the ListingsAttributes record to save. Only AFTER making the same changes am i now seeing the ListingsAttributes record saved, but the `value` from POST never makes it into the Listing Entity.

i will try again tonight, but i'm at a loss for what i can do differently. Kevin's help is the only thing that has even partially worked so far, but you're telling me that's doing it wrong. So what's left?

Thank you.


On Tuesday, 3 March 2015 10:13:53 UTC-5, José Lorenzo wrote:


On Tuesday, March 3, 2015 at 2:43:55 PM UTC+1, Joe T. wrote:
  1. Had to add `id` to the Attributes $_accessible field array (as described by heavyKevy in a post above). If making foreign table IDs available for a joint table is necessary, why isn't the bake process doing that when it analyzes the foreign key structure?
It is not needed, unless you want to do everything manual. The usual workflow where making this column accessible is not needed is when you have a code like the following

    $post = $this->Posts->get(1, ['associated' => ['Tags']]);
    $this->set(compact($post));

The $post will contain its tags with their '_joinData' (including the id). Having the id in the result is important when you render the form:


    $this->From->input('tags.0.id);
    $this->From->input('tags.0._joinData.another_column');

Based on the id of the tag, the data that was modified will be matched when you do the patch entity:

    $post = $this->Posts->patchEntity($post, $this->request->data, ['Tags._joinData']);

There are numerous tests and other apps doing this successfully, as the other person that tried to help you showed.
  1. Manually setting join data dirty after the entity patch: $listing->dirty('attributes._joinData', true); - The documentation's examples for doing this are when you manually set entity data outside an entity-related call. patchEntity implies there will be dirty data, so it should handle it internally. Besides, when it comes to editing & i go to patch the existing entity with the POST data, maybe the _joinData is unaltered, and therefore manually setting it dirty is incorrect. i can't make assumptions with the POST data on what's dirty or not. That, to me, is exactly what patchEntity is for. However, i haven't even managed to get the joint record to save without all the modifications described in Kevin's previous post.

This is not true, patchEntity will mark the property as dirty if it changed in any way. If you are certain (or very suspicious) it is not working the way it should, please open a ticket so the core team can take a look at it.
  1. In the ListingsAttributesTable validation, it doesn't seem correct that allowEmpty for the two foreign IDs should be required to save the data, but it doesn't seem to work otherwise. In fact, if either of those IDs is empty for the joint table, validation should fail, but these validations will permit it.


Those columns are going to be set automatically for you, so it makes no sense to have validation for them. Instead, use the rule system if you want to enforce some validation for foreign keys: http://book.cakephp.org/3.0/en/orm/saving-data.html#foreign-key-rules

 
And none of that explains why, after following the documentation examples & Kevin's gracious effort to help me out, why the `listings_attributes.value` column still doesn't receive the _joinData.value POST data...


Is "value" for the entity resenting the joinData accessible? Dos it pass its validation?

--
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.

No comments: