Can you show a debug of the resulting entity after patchEntity. Also, if you join the #cakephp IRC channel in freenode, I think we can help you faster :)
On Tuesday, March 3, 2015 at 6:01:25 PM UTC+1, Joe T. wrote: > > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/cake-php. For more options, visit https://groups.google.com/d/optout.
