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.
