Try not to laugh too hard: 20 years online & i've *never* used IRC. i won't
be home until 8pm (12-1a GMT) or so tonight, but if anyone is around, i'd
be grateful for the help.
Nearly everything i've posted in code blocks has been directly from the
Cake Debugger Log. The most recent POST & Entity were:
// *Log::debug($this->request->data)* :
Array
(
[attributes] => Array
(
[3] => Array
(
[id] => 1
[_joinData] => Array
(
[value] => Off-street
)
)
)
// Other field/value pairs for the Listings table
)
The Listing Entity after *patchEntity*:
// *Log::debug($listing->jsonSerialize())* :
Array
(
[attributes] => Array
(
[0] => Array
(
[id] => 1
)
)
// Other field/value pairs for the Listings table
)
On Tuesday, 3 March 2015 14:05:11 UTC-5, José Lorenzo wrote:
>
> 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.
