Yes. That was one of the first things I tried because I had extra
field info on the join table.
As the dbo_source.php code shows, it's just not allowing other ids
based on the foreign/join keys.

That's the part I'm confused about ... why not?? If the row is
duplicated it shows it, and thus also reveals an issue somewhere else
that the association was duplicated, so if anything it helps reveal
other issues (ironing out bugs).

On Oct 8, 2:51 pm, abba bryant <[EMAIL PROTECTED]> wrote:
> Have you tried creating an id field in the join table and setting that field
> and only that field to be the primary key?
>
> Brenton B wrote:
>
> > Ok, so I can kind of understand the use of `$foreignKey` as something
> > to compare on, but that still doesn't explain why we're limiting to
> > unique Ids.
>
> > Quite frustrating without an explanation.
>
> > On Oct 7, 2:28 am, Brenton B <[EMAIL PROTECTED]> wrote:
> >> Ok, so the "root" where all this non-unique stuff occurs seems to be
> >> in dbo_source.php, line 841:
>
> >>                                         if ($type ==
> >> 'hasAndBelongsToMany') {
> >>                                                 $uniqueIds = $merge =
> >> array();
>
> >>                                                 foreach($fetch as $j =>
> >> $data) {
> >>                                                         if (
>
> >> (isset($data[$with]) && $data[$with][$foreignKey] ===
> >> $row[$model->alias][$model->primaryKey]) &&
>
> >> (!in_array($data[$with][$joinKeys[1]], $uniqueIds))
> >>                                                         ) {
>
> >> $uniqueIds[] = $data[$with][$joinKeys[1]];
>
> >>                                                                 if
> >> ($habtmFieldsCount <= 2) {
>
> >> unset($data[$with]);
> >>                                                                 }
> >>                                                                 $merge[]
> >> = $data;
> >>                                                         }
> >>                                                 }
> >>                                                 if (empty($merge) &&
> >> !isset($row[$association])) {
>
> >> $row[$association] = $merge;
> >>                                                 } else {
>
> >> $this->__mergeAssociation($resultSet[$i], $merge, $association,
> >> $type);
> >>                                                 }
> >>                                         }
>
> >> Fair enough ... but why?? So this kills any possibility of showing
> >> duplicates, that might be good, but shouldn't it bring back
> >> everything, thus revealing any possibility of screwiness in app code?
>
> >> Since it's a HABTM relationship, shouldn't the whole "has and belongs
> >> to many" retrieve all that it has and belongs to?
>
> >> There's obviously something I'm missing and confused about ...
> >> unfortunately no comments in code to shed light.
>
> >> (Note: to recap, I've got a user HABTM webpage_types in users-
> >> webpage_types  with extra fields where a user could multiple of the
> >> same webpage_type)
>
> >> On Oct 6, 1:41 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> >> > So, moving to the solution nachopitt suggested "works" ... however,
> >> > because of this, for saving, I have to use `saveAll()` instead of
> >> > `save()` ... which "works"; however, for the User model, there's also
> >> > another HABTM which doesn't work for `saveAll()` ... doh!!
>
> >> > Best solution?
>
> >> > On Oct 6, 11:03 am, Brenton B <[EMAIL PROTECTED]> wrote:
>
> >> > > Well, the table looks more like this:
>
> >> > > user_id | web_page_type_id | url
>
> >> -----------------------------------------------------------------------
> >> > >     7      |          6                 | firstdomain.com
> >> > >     7      |          6                 | second.com
>
> >> > > So the two are unique, but I see what you're saying.
>
> >> > > I did originally have it setup in such a way that it wasn't a typical
> >> > > join table (as nachopitt suggested); however, was running into
> >> > > problems with saving in one fell swoop and wanted to give the "HABTM
> >> > > save setup" a try (as described everywhere).
>
> >> > > Might have to go back to the previous method.
>
> >> > > On Oct 4, 7:33 am, nachopitt <[EMAIL PROTECTED]> wrote:
>
> >> > > > Yeah, teknoid has a point. Your relation/association is not
> >> supposed
> >> > > > to work in that way. Normally, in a non CakePHP enviroment, a
> >> > > > joinTable has the 2 foreign keys and they set as the "primary key"
> >> > > > column. You don´t have the "id" column that CakePHP expects to have
> >> > > > and then the foreign keys... thats why the "uniqueness" of the
> >> > > > records.
>
> >> > > > Personally i would change the schema of you database for something
> >> > > > like
>
> >> > > > users
> >> > > > web_pages (holding the url, title, etc)
> >> > > > web_page_types (holding the name of the webpage type)
>
> >> > > > And the associations
>
> >> > > > user hasMany webpages
> >> > > > webpage belongsTo user
> >> > > > webpage belongsTo webpageType
>
> >> > > > On Oct 3, 6:37 pm, teknoid <[EMAIL PROTECTED]> wrote:
>
> >> > > > > Goes to show I should read more carefully :)
> >> > > > > I guess the title of the post made me jump the gun...
>
> >> > > > > You say "an user has 2 of the same webpage_type"
>
> >> > > > > Does it mean that in your join table you have something like: ?
> >> > > > > user_id | web_page_type_id
> >> > > > > -----------------------------------------
> >> > > > >     7      |          6
> >> > > > >     7      |          6
>
> >> > > > > On Oct 3, 6:27 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> >> > > > > > Well, assuming the Docs are correct (and I understand it
> >> properly),
> >> > > > > > that should only apply to updates ("If true (default value)
> >> cake will
> >> > > > > > first delete existing relationship records in the foreign keys
> >> table
> >> > > > > > before inserting new ones, when updating a record. So existing
> >> > > > > > associations need to be passed again when updating").
>
> >> > > > > > However, in my circumstance, I'm just retrieving information
> >> ...
>
> >> > > > > > Debug SQL shows the (as expected) query of getting all webpages
> >> &
> >> > > > > > types based on the user_id, and it retrieves all the
> >> information
> >> > > > > > that's needed; however, by the time I get to the view (where I
> >> have a
> >> > > > > > `pr()`), I've magically lost one of 'em - well, actually, any
> >> > > > > > subsequent webpage_type record that has the same id.
>
> >> > > > > > Conventions: Yeah, I know those were just there, left over from
> >> > > > > > scaffolding, so figured no harm in leaving 'em ...
>
> >> > > > > > On Oct 3, 3:19 pm, teknoid <[EMAIL PROTECTED]> wrote:
>
> >> > > > > > > Do you know what 'unique'=>true does?
>
> >> > > > > > > Btw, there really isn't any need to define default values for
> >> your
> >> > > > > > > associations if you follow the conventions.
>
> >> > > > > > > On Oct 3, 6:10 pm, Brenton B <[EMAIL PROTECTED]>
> >> wrote:
>
> >> > > > > > > > Ok, so here's the scenario ...
>
> >> > > > > > > > A user can have multiple webpages in their account, and
> >> when they set
> >> > > > > > > > them up, they must choose the type (ex: blog, gallery,
> >> etc). So User
> >> > > > > > > >HABTMwebpage_type ... where users_webpage_types has
> >> additional fields
> >> > > > > > > > for URL, title, etc.
>
> >> > > > > > > > The thing I'm running into is upon retrieving: If an user
> >> has 2 of the
> >> > > > > > > > same webpage_type, it performs the SQL to get 'em all, but
> >> once it's
> >> > > > > > > > done it's magic, it only has the first record. I'm assuming
> >> this is
> >> > > > > > > > due to the occurrence of the same webpage_type_id, but
> >> still lost ...
>
> >> > > > > > > > User::
>
> >> > > > > > > >         var $hasAndBelongsToMany = array(
> >> > > > > > > >                         'WebpageType' => array('className'
> >> => 'WebpageType',
> >> > > > > > > >                                                 'joinTable'
> >> => 'users_webpage_types',
>
> >> 'foreignKey' => 'userr_id',
>
> >> 'associationForeignKey' => 'webpage_type_id',
> >> > > > > > > >                                                 'with' =>
> >> 'UsersWebpageType',
> >> > > > > > > >                                                 'unique' =>
> >> true,
> >> > > > > > > >                         ),
>
> >> > > > > > > > WebpageType::
>
> >> > > > > > > >         var $hasAndBelongsToMany = array(
> >> > > > > > > >                         'User' => array('className' =>
> >> 'User',
> >> > > > > > > >                                                 'joinTable'
> >> => 'users_webpage_types',
>
> >> 'foreignKey' => 'webpage_type_id',
>
> >> 'associationForeignKey' => 'user_id',
> >> > > > > > > >                                                 'with' =>
> >> 'UsersWebpageType',
> >> > > > > > > >                                                 'unique' =>
> >> true,
>
> >> > > > > > > > UsersWebpageType::
>
> >> > > > > > > >         var $belongsTo = array(
> >> > > > > > > >                         'User' => array('className' =>
> >> 'User',
>
> >> 'foreignKey' => 'user_id',
>
> >> 'conditions' => '',
>
> >> 'fields' => '',
>
> >> 'order' => ''
> >> > > > > > > >                         ),
> >> > > > > > > >                         'WebpageType' => array('className'
> >> => 'WebpageType',
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"CakePHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to