Tree Behaviour > reorder (parent_id NULL)
Just a note to hopefully help others avoid some confusion ... When using the Tree Behaviour, the table should be setup such that it allows NULL, with it being the default. I know the http://book.cakephp.org/view/228/Basic-Usage page shows the SQL as such; however, I have this crazy habit of not allowing null if it doesn't have to be. The docs don't clearly state it must be null, so figured it would be ok. However, after getting frustrated with the `reorder()` function, I finally discovered that parent_id can't be '0', but 'null' if it's at the top. Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. 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 cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: Not so elegant implementation of mysql SQL_CACHE
Looks like a good start. I've been meaning to tweak some queries to make use of SQL_CACHE as well ... maybe that could be a feature request for the core. Shouldn't be too hard to add a class var $sql_cache and have it be of type bool to be able to model-specific caching on SELECT statements. Would be immensely handy for somewhat static look-up tables. On Jan 21, 12:30 pm, "Websta*" wrote: > We needed to implemnt mysql query cache in our querries in a few > places, and the first implmentation of this ended up being the > following: > > http://pastebin.com/mb4f95ad > > it was just whipped together quickly, and im not endorsing the use of > this code to everyone, just thought someone might be interested, or > someone might have a better/simpler or less hackish feeling solution. > but alas it provides what we wanted for now. comments welcome. > > implement by addingSQL_CACHEto your fields param of your model > methods --~--~-~--~~~---~--~~ 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 cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~--~~~~--~~--~--~---
Save + HABTM != beforeDelete()
Scenario:
Members <- HABTM -> Webpages.
When a member edits their info there is also a big list of different
webpages they can check/uncheck ... when they go to save it will
delete the joins then re-add them. When it deletes them, it does so in
a way that `beforeDelete()` nor `afterDelete()` are called.
/cake/libs/model/model.php lines 1315 - 1330:
if ($this->hasAndBelongsToMany[$assoc]['unique']) {
$associationForeignKey = "{$join}." . $this->hasAndBelongsToMany
[$assoc]['associationForeignKey'];
$oldLinks = Set::extract($links, "{n}.{$associationForeignKey}");
if (!empty($oldLinks)) {
$conditions[$associationForeignKey] = $oldLinks;
$db->delete($this->{$join}, $conditions);
}
}
if (!empty($newData)) {
foreach ($newData as $data) {
$data[$this->hasAndBelongsToMany[$assoc]['foreignKey']] = $id;
$this->{$join}->create($data);
$this->{$join}->save();
}
}
--
My question is: why? What do I do if I want to trigger a `beforeDelete
()` call?
Logically I would assume that creating a join-table model (in my
scenario MemberWebpage) and throwing it in there would solve that, but
obviously from the above code this would never get called ... so ...
is this intentional or a bug??
--~--~-~--~~~---~--~~
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
cake-php+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
-~--~~~~--~~--~--~---
Re: Confusion with $uniqueIds in dbo_source.php
I completely agree ... ... but by filtering out the unique ids you're covering up a potential problem that would otherwise be exposed. Shouldn't it be up to the application to ensure things are/aren't unique? On Jan 17, 7:28 pm, Nate wrote: > In my book, something needs to be broken before it should be > fixed. ;-) > > In a default HABTM relationship, multiple records with the same > foreign key pair are not allowed. Simple as that. If you want to do > something custom, set 'unique' to false, and/or create a join model > and set up your associations (both of them) to use it. > > On Jan 17, 9:06 pm, Brenton B wrote: > > > After a bit of a hiatus, I'm back ... and very saddened to see this > > still isn't fixed ... > > seriously? Has no one else run into this?? > > > On Nov 28 2008, 1:25 pm, Brenton B wrote: > > > > Yup, and was met with a "need test case" reply ... which I understand > > > is required ... unfortunately I don't have time as of late to create > > > one. > > > If you have the time, go nuts ... otherwise I'm hoping to get to it in > > > the next few weeks. > > > > On Nov 15, 3:14 pm, Mauro Zadu wrote: > > > > > I'm with you Brenton! Can you share the modification you made to > > > > dbo_source.php? Did you consider open a ticket with this issue? > > > > Thank you > > > > > On 4 nov, 06:43, Brenton B wrote: > > > > > > Still no love, hey? > > > > > I'm not sure how else to explain this other than to ask why > > > > > dbo_source.php is over-writing. --~--~-~--~~~---~--~~ 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 cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~--~~~~--~~--~--~---
Re: Finds: Contain vs. Unbind-on-the-fly
Anyone had any luck with these? There are still a ridiculous amount of large queries going on. On Nov 28 2008, 1:22 pm, Brenton B wrote: > Overall, looks like 'depth' and 'recursive' are conflicting and > causing the extra queries. > Anyone had the time to take look? > > When this is combined with some (somewhat) basic search/finds, it > exhausts the memory size because so much is going on. > > On Nov 10, 5:32 pm, Brenton B wrote: > > > After digging around some more, I'm thinking this needs to be > > scrutinized. > > Unfortunately I haven't had much time lately to really pick it apart, > > but will keep updating when I find stuff. > > > On Nov 7, 12:12 pm, "Xavier Mathews" wrote: > > > > Yeah there is some extra queries and something not right with the ones > > > that > > > already in place! > > > > Xavier A. Mathews > > > Student/Developer/Web-Master > > > GG Client Based Tech Support Specialist > > > Hazel Crest Illinois > > > xavieruni...@gmail.com¥xavieruni...@hotmail.com¥truestar...@yahoo.com > > > "Fear of a name, only increases fear of the thing itself." > > > > On Fri, Nov 7, 2008 at 2:04 PM, Brenton B > > > wrote: > > > > > Wee bit of a running commentary here ... > > > > > containable.php > > > > > Line 348 has 'depth' being increased with each level (as it does the > > > > foreach), then subsequently assigned on line 359. > > > > > This looks like it's set for all models and not just the ones needed, > > > > hence the possibility of extra queries. > > > > > Confirmed on line 171 where it's recursivity is then set based on > > > > 'depth'. (possibly). > > > > > Will continue looking > > > > > On Nov 7, 11:13 am, Brenton B wrote: > > > > > Re: "why is it try to select models with id=2": > > > > > > Because thats the value of country_id and state_id in the Photographer > > > > > record that's being selected: > > > > > WHERE `Photographer`.`id` = 1 > > > > > > On Nov 6, 8:35 pm, teknoid wrote: > > > > > > > That's very strange... why is it trying to select models with id=2? > > > > > > Doesn't seem like you pass any conditions to your find()... > > > > > > Are you sure there is nothing else going (maybe in model > > > > > > associations) > > > > > > or any other attached behaviors? > > > > > > > On Nov 6, 6:34 pm, Brenton B wrote: > > > > > > > > Where there is only 1 level in the 'contain': > > > > > > > > SELECT `Photographer`.`id`, `Photographer`.`first_name`, > > > > > > > `Photographer`.`last_name`, `Photographer`.`company_name`, > > > > > > > `Photographer`.`email`, `Photographer`.`telephone`, > > > > > > > `Photographer`.`address_1`, `Photographer`.`address_2`, > > > > > > > `Photographer`.`country_id`, `Photographer`.`state_id`, > > > > > > > `Photographer`.`city`, `Photographer`.`zip_code`, [[[... plus a > > > > bunch > > > > > > > of other fields ... ]]] `Country`.`id`, `Country`.`name`, > > > > > > > `Country`.`created`, `Country`.`created_by`, `Country`.`modified`, > > > > > > > `Country`.`modified_by`, `State`.`id`, `State`.`name`, > > > > > > > `State`.`country_id`, `State`.`created`, `State`.`created_by`, > > > > > > > `State`.`modified`, `State`.`modified_by` FROM `photographers` AS > > > > > > > `Photographer` LEFT JOIN `countries` AS `Country` ON > > > > > > > (`Photographer`.`country_id` = `Country`.`id`) LEFT JOIN `states` > > > > > > > AS > > > > > > > `State` ON (`Photographer`.`state_id` = `State`.`id`) WHERE > > > > > > > `Photographer`.`id` = 1 LIMIT 1 > > > > > > > > SELECT `PrintSize`.`id`, `PrintSize`.`name`, > > > > > > > `PrintSize`.`created`, > > > > > > > `PrintSize`.`created_by`, `PrintSize`.`modified`, > > > > > > > `PrintSize`.`modified_by`, `PhotographersPrintSize`.`id`, > > > > > > > `PhotographersPrintSize`.`photographer_id`, > > > > > > > `PhotographersPrintSize`.`print_size_id`, > > > > > > > `PhotographersPrintSiz
Re: Confusion with $uniqueIds in dbo_source.php
After a bit of a hiatus, I'm back ... and very saddened to see this still isn't fixed ... seriously? Has no one else run into this?? On Nov 28 2008, 1:25 pm, Brenton B wrote: > Yup, and was met with a "need test case" reply ... which I understand > is required ... unfortunately I don't have time as of late to create > one. > If you have the time, go nuts ... otherwise I'm hoping to get to it in > the next few weeks. > > On Nov 15, 3:14 pm, Mauro Zadu wrote: > > > I'm with you Brenton! Can you share the modification you made to > > dbo_source.php? Did you consider open a ticket with this issue? > > Thank you > > > On 4 nov, 06:43, Brenton B wrote: > > > > Still no love, hey? > > > I'm not sure how else to explain this other than to ask why > > > dbo_source.php is over-writing. --~--~-~--~~~---~--~~ 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 cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~--~~~~--~~--~--~---
Re: Confusion with $uniqueIds in dbo_source.php
Yup, and was met with a "need test case" reply ... which I understand is required ... unfortunately I don't have time as of late to create one. If you have the time, go nuts ... otherwise I'm hoping to get to it in the next few weeks. On Nov 15, 3:14 pm, Mauro Zadu <[EMAIL PROTECTED]> wrote: > I'm with you Brenton! Can you share the modification you made to > dbo_source.php? Did you consider open a ticket with this issue? > Thank you > > On 4 nov, 06:43, Brenton B <[EMAIL PROTECTED]> wrote: > > > Still no love, hey? > > I'm not sure how else to explain this other than to ask why > > dbo_source.php is over-writing. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Ajax ObserField "Form is not defined"
Not sure if it was this or something else ... but I had a nested form
by accident, which is not valid, clearing this up helped things.
On Nov 4, 8:49 pm, Brenton B <[EMAIL PROTECTED]> wrote:
> I think I'm running into something similar with 1.2 and AJAX
> submit ... however, could potentially be a compatibility issue with
> Prototype.
>
> On Sep 16, 4:51 am, AussieFreelancer <[EMAIL PROTECTED]>
> wrote:
>
> > anyone, anyone... does observeField actually work in 1.1? I have it
> > working in 1.2 ok, but this project uses 1.1
>
> > On Aug 5, 4:37 pm, AussieFreelancer <[EMAIL PROTECTED]>
> > wrote:
>
> > > Hi all, I am trying to get a chained select working using the code
> > > found here: (5th post)
>
> > >http://groups.google.com/group/cake-php/browse_thread/thread/b9eb6c15...
>
> > > However when I run it, it doesn't work, and the error console tells me
> > > that "Form is not defined". From looking at the source code, I can see
> > > that the observeField has added the following code:
>
> > > new
> > > Form.Element.Observer('JobsCompanyId', 1, function(element, value)
> > > {new Ajax.Updater('jobs_select_sites','/sites/ajax_sites/',
> > > {asynchronous:true, evalScripts:true,
> > > parameters:Form.Element.serialize('JobsCompanyId'), requestHeaders:['X-
> > > Update', 'jobs_select_sites']})})
>
> > > So I can see where the Form bit comes from, but am unsure as to why it
> > > is undefined. I have added theprototypeand scriptaculous libs to /
> > > app/webroot/js and included them in the page head.
>
> > > I am using 1.1 for this project, and would love to have this working,
> > > as this is just the start of the chained select development (I have 3
> > > multiple select boxes)
>
> > > Any help someone can offer would be hugely appreciated.
>
> > > Thanks
>
> > > Patrick
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Finds: Contain vs. Unbind-on-the-fly
Overall, looks like 'depth' and 'recursive' are conflicting and causing the extra queries. Anyone had the time to take look? When this is combined with some (somewhat) basic search/finds, it exhausts the memory size because so much is going on. On Nov 10, 5:32 pm, Brenton B <[EMAIL PROTECTED]> wrote: > After digging around some more, I'm thinking this needs to be > scrutinized. > Unfortunately I haven't had much time lately to really pick it apart, > but will keep updating when I find stuff. > > On Nov 7, 12:12 pm, "Xavier Mathews" <[EMAIL PROTECTED]> wrote: > > > Yeah there is some extra queries and something not right with the ones that > > already in place! > > > Xavier A. Mathews > > Student/Developer/Web-Master > > GG Client Based Tech Support Specialist > > Hazel Crest Illinois > > [EMAIL PROTECTED]@[EMAIL PROTECTED] > > "Fear of a name, only increases fear of the thing itself." > > > On Fri, Nov 7, 2008 at 2:04 PM, Brenton B <[EMAIL PROTECTED]> wrote: > > > > Wee bit of a running commentary here ... > > > > containable.php > > > > Line 348 has 'depth' being increased with each level (as it does the > > > foreach), then subsequently assigned on line 359. > > > > This looks like it's set for all models and not just the ones needed, > > > hence the possibility of extra queries. > > > > Confirmed on line 171 where it's recursivity is then set based on > > > 'depth'. (possibly). > > > > Will continue looking > > > > On Nov 7, 11:13 am, Brenton B <[EMAIL PROTECTED]> wrote: > > > > Re: "why is it try to select models with id=2": > > > > > Because thats the value of country_id and state_id in the Photographer > > > > record that's being selected: > > > > WHERE `Photographer`.`id` = 1 > > > > > On Nov 6, 8:35 pm, teknoid <[EMAIL PROTECTED]> wrote: > > > > > > That's very strange... why is it trying to select models with id=2? > > > > > Doesn't seem like you pass any conditions to your find()... > > > > > Are you sure there is nothing else going (maybe in model associations) > > > > > or any other attached behaviors? > > > > > > On Nov 6, 6:34 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > > > > > Where there is only 1 level in the 'contain': > > > > > > > SELECT `Photographer`.`id`, `Photographer`.`first_name`, > > > > > > `Photographer`.`last_name`, `Photographer`.`company_name`, > > > > > > `Photographer`.`email`, `Photographer`.`telephone`, > > > > > > `Photographer`.`address_1`, `Photographer`.`address_2`, > > > > > > `Photographer`.`country_id`, `Photographer`.`state_id`, > > > > > > `Photographer`.`city`, `Photographer`.`zip_code`, [[[... plus a > > > bunch > > > > > > of other fields ... ]]] `Country`.`id`, `Country`.`name`, > > > > > > `Country`.`created`, `Country`.`created_by`, `Country`.`modified`, > > > > > > `Country`.`modified_by`, `State`.`id`, `State`.`name`, > > > > > > `State`.`country_id`, `State`.`created`, `State`.`created_by`, > > > > > > `State`.`modified`, `State`.`modified_by` FROM `photographers` AS > > > > > > `Photographer` LEFT JOIN `countries` AS `Country` ON > > > > > > (`Photographer`.`country_id` = `Country`.`id`) LEFT JOIN `states` AS > > > > > > `State` ON (`Photographer`.`state_id` = `State`.`id`) WHERE > > > > > > `Photographer`.`id` = 1 LIMIT 1 > > > > > > > SELECT `PrintSize`.`id`, `PrintSize`.`name`, `PrintSize`.`created`, > > > > > > `PrintSize`.`created_by`, `PrintSize`.`modified`, > > > > > > `PrintSize`.`modified_by`, `PhotographersPrintSize`.`id`, > > > > > > `PhotographersPrintSize`.`photographer_id`, > > > > > > `PhotographersPrintSize`.`print_size_id`, > > > > > > `PhotographersPrintSize`.`price`, > > > > > > `PhotographersPrintSize`.`comment`, > > > > > > `PhotographersPrintSize`.`created`, > > > > > > `PhotographersPrintSize`.`created_by`, > > > > > > `PhotographersPrintSize`.`modified`, > > > > > > `PhotographersPrintSize`.`modified_by` FROM `print_sizes` AS > > > > > > `PrintSize` JOIN `photographers_print_sizes` AS > > > > > > `Photo
Re: Finds: Contain vs. Unbind-on-the-fly
After digging around some more, I'm thinking this needs to be scrutinized. Unfortunately I haven't had much time lately to really pick it apart, but will keep updating when I find stuff. On Nov 7, 12:12 pm, "Xavier Mathews" <[EMAIL PROTECTED]> wrote: > Yeah there is some extra queries and something not right with the ones that > already in place! > > Xavier A. Mathews > Student/Developer/Web-Master > GG Client Based Tech Support Specialist > Hazel Crest Illinois > [EMAIL PROTECTED]@[EMAIL PROTECTED] > "Fear of a name, only increases fear of the thing itself." > > On Fri, Nov 7, 2008 at 2:04 PM, Brenton B <[EMAIL PROTECTED]> wrote: > > > Wee bit of a running commentary here ... > > > containable.php > > > Line 348 has 'depth' being increased with each level (as it does the > > foreach), then subsequently assigned on line 359. > > > This looks like it's set for all models and not just the ones needed, > > hence the possibility of extra queries. > > > Confirmed on line 171 where it's recursivity is then set based on > > 'depth'. (possibly). > > > Will continue looking > > > On Nov 7, 11:13 am, Brenton B <[EMAIL PROTECTED]> wrote: > > > Re: "why is it try to select models with id=2": > > > > Because thats the value of country_id and state_id in the Photographer > > > record that's being selected: > > > WHERE `Photographer`.`id` = 1 > > > > On Nov 6, 8:35 pm, teknoid <[EMAIL PROTECTED]> wrote: > > > > > That's very strange... why is it trying to select models with id=2? > > > > Doesn't seem like you pass any conditions to your find()... > > > > Are you sure there is nothing else going (maybe in model associations) > > > > or any other attached behaviors? > > > > > On Nov 6, 6:34 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > > > > Where there is only 1 level in the 'contain': > > > > > > SELECT `Photographer`.`id`, `Photographer`.`first_name`, > > > > > `Photographer`.`last_name`, `Photographer`.`company_name`, > > > > > `Photographer`.`email`, `Photographer`.`telephone`, > > > > > `Photographer`.`address_1`, `Photographer`.`address_2`, > > > > > `Photographer`.`country_id`, `Photographer`.`state_id`, > > > > > `Photographer`.`city`, `Photographer`.`zip_code`, [[[... plus a > > bunch > > > > > of other fields ... ]]] `Country`.`id`, `Country`.`name`, > > > > > `Country`.`created`, `Country`.`created_by`, `Country`.`modified`, > > > > > `Country`.`modified_by`, `State`.`id`, `State`.`name`, > > > > > `State`.`country_id`, `State`.`created`, `State`.`created_by`, > > > > > `State`.`modified`, `State`.`modified_by` FROM `photographers` AS > > > > > `Photographer` LEFT JOIN `countries` AS `Country` ON > > > > > (`Photographer`.`country_id` = `Country`.`id`) LEFT JOIN `states` AS > > > > > `State` ON (`Photographer`.`state_id` = `State`.`id`) WHERE > > > > > `Photographer`.`id` = 1 LIMIT 1 > > > > > > SELECT `PrintSize`.`id`, `PrintSize`.`name`, `PrintSize`.`created`, > > > > > `PrintSize`.`created_by`, `PrintSize`.`modified`, > > > > > `PrintSize`.`modified_by`, `PhotographersPrintSize`.`id`, > > > > > `PhotographersPrintSize`.`photographer_id`, > > > > > `PhotographersPrintSize`.`print_size_id`, > > > > > `PhotographersPrintSize`.`price`, `PhotographersPrintSize`.`comment`, > > > > > `PhotographersPrintSize`.`created`, > > > > > `PhotographersPrintSize`.`created_by`, > > > > > `PhotographersPrintSize`.`modified`, > > > > > `PhotographersPrintSize`.`modified_by` FROM `print_sizes` AS > > > > > `PrintSize` JOIN `photographers_print_sizes` AS > > > > > `PhotographersPrintSize` ON > > > > > (`PhotographersPrintSize`.`photographer_id` = 1 AND > > > > > `PhotographersPrintSize`.`print_size_id` = `PrintSize`.`id`) WHERE 1 > > = > > > > > 1 > > > > > > Then as soon as I add in the extra level in 'contain' I get the > > above, > > > > > plus these extras: > > > > > > SELECT `Country`.`id`, `Country`.`name`, `Country`.`created`, > > > > > `Country`.`created_by`, `Country`.`modified`, `Country`.`modified_by` > > > > > FROM `countries` AS `Country` WHERE `Country`.`id` = 2 > > > >
Re: Finds: Contain vs. Unbind-on-the-fly
Wee bit of a running commentary here ... containable.php Line 348 has 'depth' being increased with each level (as it does the foreach), then subsequently assigned on line 359. This looks like it's set for all models and not just the ones needed, hence the possibility of extra queries. Confirmed on line 171 where it's recursivity is then set based on 'depth'. (possibly). Will continue looking On Nov 7, 11:13 am, Brenton B <[EMAIL PROTECTED]> wrote: > Re: "why is it try to select models with id=2": > > Because thats the value of country_id and state_id in the Photographer > record that's being selected: > WHERE `Photographer`.`id` = 1 > > On Nov 6, 8:35 pm, teknoid <[EMAIL PROTECTED]> wrote: > > > That's very strange... why is it trying to select models with id=2? > > Doesn't seem like you pass any conditions to your find()... > > Are you sure there is nothing else going (maybe in model associations) > > or any other attached behaviors? > > > On Nov 6, 6:34 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > > Where there is only 1 level in the 'contain': > > > > SELECT `Photographer`.`id`, `Photographer`.`first_name`, > > > `Photographer`.`last_name`, `Photographer`.`company_name`, > > > `Photographer`.`email`, `Photographer`.`telephone`, > > > `Photographer`.`address_1`, `Photographer`.`address_2`, > > > `Photographer`.`country_id`, `Photographer`.`state_id`, > > > `Photographer`.`city`, `Photographer`.`zip_code`, [[[... plus a bunch > > > of other fields ... ]]] `Country`.`id`, `Country`.`name`, > > > `Country`.`created`, `Country`.`created_by`, `Country`.`modified`, > > > `Country`.`modified_by`, `State`.`id`, `State`.`name`, > > > `State`.`country_id`, `State`.`created`, `State`.`created_by`, > > > `State`.`modified`, `State`.`modified_by` FROM `photographers` AS > > > `Photographer` LEFT JOIN `countries` AS `Country` ON > > > (`Photographer`.`country_id` = `Country`.`id`) LEFT JOIN `states` AS > > > `State` ON (`Photographer`.`state_id` = `State`.`id`) WHERE > > > `Photographer`.`id` = 1 LIMIT 1 > > > > SELECT `PrintSize`.`id`, `PrintSize`.`name`, `PrintSize`.`created`, > > > `PrintSize`.`created_by`, `PrintSize`.`modified`, > > > `PrintSize`.`modified_by`, `PhotographersPrintSize`.`id`, > > > `PhotographersPrintSize`.`photographer_id`, > > > `PhotographersPrintSize`.`print_size_id`, > > > `PhotographersPrintSize`.`price`, `PhotographersPrintSize`.`comment`, > > > `PhotographersPrintSize`.`created`, > > > `PhotographersPrintSize`.`created_by`, > > > `PhotographersPrintSize`.`modified`, > > > `PhotographersPrintSize`.`modified_by` FROM `print_sizes` AS > > > `PrintSize` JOIN `photographers_print_sizes` AS > > > `PhotographersPrintSize` ON > > > (`PhotographersPrintSize`.`photographer_id` = 1 AND > > > `PhotographersPrintSize`.`print_size_id` = `PrintSize`.`id`) WHERE 1 = > > > 1 > > > > Then as soon as I add in the extra level in 'contain' I get the above, > > > plus these extras: > > > > SELECT `Country`.`id`, `Country`.`name`, `Country`.`created`, > > > `Country`.`created_by`, `Country`.`modified`, `Country`.`modified_by` > > > FROM `countries` AS `Country` WHERE `Country`.`id` = 2 > > > > SELECT `State`.`id`, `State`.`name`, `State`.`country_id`, > > > `State`.`created`, `State`.`created_by`, `State`.`modified`, > > > `State`.`modified_by` FROM `states` AS `State` WHERE `State`.`id` = 2 > > > > I'm hoping to have some time tonight to really dig through the > > > Containable behaviour code. > > > > On Nov 6, 3:03 pm, teknoid <[EMAIL PROTECTED]> wrote: > > > > > What are the "extra" queries, which get generated for Country and > > > > State, when you add other models? > > > > Could you provide an example? > > > > > On Nov 6, 5:41 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > > > > Photographer: > > > > > Photographer belongsTo Country > > > > > Photographer belongsTo State > > > > > Photographer HABTM PrintSize: with PhotographersPrintSize > > > > > (join table > > > > > has extra data) > > > > > > PrintSize: > > > > > PrintSize HABTM Photographer: with PhotographersPrintSize > > > > > (again, > > > > > join table with data) > > > > > > PhotographersPrintSi
Re: Finds: Contain vs. Unbind-on-the-fly
Re: "why is it try to select models with id=2":
Because thats the value of country_id and state_id in the Photographer
record that's being selected:
WHERE `Photographer`.`id` = 1
On Nov 6, 8:35 pm, teknoid <[EMAIL PROTECTED]> wrote:
> That's very strange... why is it trying to select models with id=2?
> Doesn't seem like you pass any conditions to your find()...
> Are you sure there is nothing else going (maybe in model associations)
> or any other attached behaviors?
>
> On Nov 6, 6:34 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > Where there is only 1 level in the 'contain':
>
> > SELECT `Photographer`.`id`, `Photographer`.`first_name`,
> > `Photographer`.`last_name`, `Photographer`.`company_name`,
> > `Photographer`.`email`, `Photographer`.`telephone`,
> > `Photographer`.`address_1`, `Photographer`.`address_2`,
> > `Photographer`.`country_id`, `Photographer`.`state_id`,
> > `Photographer`.`city`, `Photographer`.`zip_code`, [[[... plus a bunch
> > of other fields ... ]]] `Country`.`id`, `Country`.`name`,
> > `Country`.`created`, `Country`.`created_by`, `Country`.`modified`,
> > `Country`.`modified_by`, `State`.`id`, `State`.`name`,
> > `State`.`country_id`, `State`.`created`, `State`.`created_by`,
> > `State`.`modified`, `State`.`modified_by` FROM `photographers` AS
> > `Photographer` LEFT JOIN `countries` AS `Country` ON
> > (`Photographer`.`country_id` = `Country`.`id`) LEFT JOIN `states` AS
> > `State` ON (`Photographer`.`state_id` = `State`.`id`) WHERE
> > `Photographer`.`id` = 1 LIMIT 1
>
> > SELECT `PrintSize`.`id`, `PrintSize`.`name`, `PrintSize`.`created`,
> > `PrintSize`.`created_by`, `PrintSize`.`modified`,
> > `PrintSize`.`modified_by`, `PhotographersPrintSize`.`id`,
> > `PhotographersPrintSize`.`photographer_id`,
> > `PhotographersPrintSize`.`print_size_id`,
> > `PhotographersPrintSize`.`price`, `PhotographersPrintSize`.`comment`,
> > `PhotographersPrintSize`.`created`,
> > `PhotographersPrintSize`.`created_by`,
> > `PhotographersPrintSize`.`modified`,
> > `PhotographersPrintSize`.`modified_by` FROM `print_sizes` AS
> > `PrintSize` JOIN `photographers_print_sizes` AS
> > `PhotographersPrintSize` ON
> > (`PhotographersPrintSize`.`photographer_id` = 1 AND
> > `PhotographersPrintSize`.`print_size_id` = `PrintSize`.`id`) WHERE 1 =
> > 1
>
> > Then as soon as I add in the extra level in 'contain' I get the above,
> > plus these extras:
>
> > SELECT `Country`.`id`, `Country`.`name`, `Country`.`created`,
> > `Country`.`created_by`, `Country`.`modified`, `Country`.`modified_by`
> > FROM `countries` AS `Country` WHERE `Country`.`id` = 2
>
> > SELECT `State`.`id`, `State`.`name`, `State`.`country_id`,
> > `State`.`created`, `State`.`created_by`, `State`.`modified`,
> > `State`.`modified_by` FROM `states` AS `State` WHERE `State`.`id` = 2
>
> > I'm hoping to have some time tonight to really dig through the
> > Containable behaviour code.
>
> > On Nov 6, 3:03 pm, teknoid <[EMAIL PROTECTED]> wrote:
>
> > > What are the "extra" queries, which get generated for Country and
> > > State, when you add other models?
> > > Could you provide an example?
>
> > > On Nov 6, 5:41 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > > > Photographer:
> > > > Photographer belongsTo Country
> > > > Photographer belongsTo State
> > > > Photographer HABTM PrintSize: with PhotographersPrintSize (join
> > > > table
> > > > has extra data)
>
> > > > PrintSize:
> > > > PrintSize HABTM Photographer: with PhotographersPrintSize
> > > > (again,
> > > > join table with data)
>
> > > > PhotographersPrintSize:
> > > > PhotographersPrintSize hasMany Photographer
> > > > PhotographersPrintSize hasMany PrintSize
>
> > > > yes, all in same db.
>
> > > > Also, forgot to mention, if I take off to recursive level (as below),
> > > > it does it fine without all the extra queries.
>
> > > > $this->set('photographer',
> > > > $this->Photographer->find('first',
> > > > array('contain'
> > > > => array(
> > > >
> > > > 'Country',
> > > >
Re: Finds: Contain vs. Unbind-on-the-fly
Where there is only 1 level in the 'contain':
SELECT `Photographer`.`id`, `Photographer`.`first_name`,
`Photographer`.`last_name`, `Photographer`.`company_name`,
`Photographer`.`email`, `Photographer`.`telephone`,
`Photographer`.`address_1`, `Photographer`.`address_2`,
`Photographer`.`country_id`, `Photographer`.`state_id`,
`Photographer`.`city`, `Photographer`.`zip_code`, [[[... plus a bunch
of other fields ... ]]] `Country`.`id`, `Country`.`name`,
`Country`.`created`, `Country`.`created_by`, `Country`.`modified`,
`Country`.`modified_by`, `State`.`id`, `State`.`name`,
`State`.`country_id`, `State`.`created`, `State`.`created_by`,
`State`.`modified`, `State`.`modified_by` FROM `photographers` AS
`Photographer` LEFT JOIN `countries` AS `Country` ON
(`Photographer`.`country_id` = `Country`.`id`) LEFT JOIN `states` AS
`State` ON (`Photographer`.`state_id` = `State`.`id`) WHERE
`Photographer`.`id` = 1 LIMIT 1
SELECT `PrintSize`.`id`, `PrintSize`.`name`, `PrintSize`.`created`,
`PrintSize`.`created_by`, `PrintSize`.`modified`,
`PrintSize`.`modified_by`, `PhotographersPrintSize`.`id`,
`PhotographersPrintSize`.`photographer_id`,
`PhotographersPrintSize`.`print_size_id`,
`PhotographersPrintSize`.`price`, `PhotographersPrintSize`.`comment`,
`PhotographersPrintSize`.`created`,
`PhotographersPrintSize`.`created_by`,
`PhotographersPrintSize`.`modified`,
`PhotographersPrintSize`.`modified_by` FROM `print_sizes` AS
`PrintSize` JOIN `photographers_print_sizes` AS
`PhotographersPrintSize` ON
(`PhotographersPrintSize`.`photographer_id` = 1 AND
`PhotographersPrintSize`.`print_size_id` = `PrintSize`.`id`) WHERE 1 =
1
Then as soon as I add in the extra level in 'contain' I get the above,
plus these extras:
SELECT `Country`.`id`, `Country`.`name`, `Country`.`created`,
`Country`.`created_by`, `Country`.`modified`, `Country`.`modified_by`
FROM `countries` AS `Country` WHERE `Country`.`id` = 2
SELECT `State`.`id`, `State`.`name`, `State`.`country_id`,
`State`.`created`, `State`.`created_by`, `State`.`modified`,
`State`.`modified_by` FROM `states` AS `State` WHERE `State`.`id` = 2
I'm hoping to have some time tonight to really dig through the
Containable behaviour code.
On Nov 6, 3:03 pm, teknoid <[EMAIL PROTECTED]> wrote:
> What are the "extra" queries, which get generated for Country and
> State, when you add other models?
> Could you provide an example?
>
> On Nov 6, 5:41 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > Photographer:
> > Photographer belongsTo Country
> > Photographer belongsTo State
> > Photographer HABTM PrintSize: with PhotographersPrintSize (join
> > table
> > has extra data)
>
> > PrintSize:
> > PrintSize HABTM Photographer: with PhotographersPrintSize (again,
> > join table with data)
>
> > PhotographersPrintSize:
> > PhotographersPrintSize hasMany Photographer
> > PhotographersPrintSize hasMany PrintSize
>
> > yes, all in same db.
>
> > Also, forgot to mention, if I take off to recursive level (as below),
> > it does it fine without all the extra queries.
>
> > $this->set('photographer',
> > $this->Photographer->find('first',
> > array('contain' =>
> > array(
> > 'Country',
> > 'State',
> >
> > 'PrintSize';
>
> > On Nov 6, 2:18 pm, teknoid <[EMAIL PROTECTED]> wrote:
>
> > > what's the relation between all those models?
> > > and are they all in the same db?
>
> > > On Nov 6, 5:12 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > > > Aha!!!
> > > > I think I've come up with the reason ...
>
> > > > As I was trying to produce a nice a short example I realized that when
> > > > there's only 1 level it doesn't produce the extra queries ... as soon
> > > > as there's more than 1 level it has the extra queries.
>
> > > > So if I have:
>
> > > > $this->set('photographer',
> > > > $this->Photographer->find('first',
> > > >
> > > > array('contain' => array(
> > > >
> > > > 'Country&#
Re: Finds: Contain vs. Unbind-on-the-fly
Photographer:
Photographer belongsTo Country
Photographer belongsTo State
Photographer HABTM PrintSize: with PhotographersPrintSize (join table
has extra data)
PrintSize:
PrintSize HABTM Photographer: with PhotographersPrintSize (again,
join table with data)
PhotographersPrintSize:
PhotographersPrintSize hasMany Photographer
PhotographersPrintSize hasMany PrintSize
yes, all in same db.
Also, forgot to mention, if I take off to recursive level (as below),
it does it fine without all the extra queries.
$this->set('photographer',
$this->Photographer->find('first',
array('contain' =>
array(
'Country',
'State',
'PrintSize';
On Nov 6, 2:18 pm, teknoid <[EMAIL PROTECTED]> wrote:
> what's the relation between all those models?
> and are they all in the same db?
>
> On Nov 6, 5:12 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > Aha!!!
> > I think I've come up with the reason ...
>
> > As I was trying to produce a nice a short example I realized that when
> > there's only 1 level it doesn't produce the extra queries ... as soon
> > as there's more than 1 level it has the extra queries.
>
> > So if I have:
>
> > $this->set('photographer',
> > $this->Photographer->find('first',
> >
> > array('contain' => array(
> >
> > 'Country',
> >
> > 'State';
>
> > Then there's no problem, but if I have
>
> > $this->set('photographer',
> > $this->Photographer->find('first',
> >
> > array('contain' => array(
> >
> > 'Country',
> >
> > 'State',
> >
> > 'PrintSize.PhotographersPrintSize';
>
> > Then it'll do extra queries on Country and State, in addition to
> > PrintSize and PhotographersPrintSize.
>
> > Even if I change it to
>
> > $this->set('photographer',
> > $this->Photographer->find('first',
> >
> > array('contain' => array(
> >
> > 'Country',
> >
> > 'State',
> >
> > 'PrintSize' => array('PhotographersPrintSize');
>
> > I still run into the issue.
>
> > BTW:
>
> > class AppModel extends Model {
>
> > var $actsAs = array('Containable');
>
> > }
>
> > I suspect it's something to do with recursive, but will keep digging.
>
> > On Nov 6, 8:33 am, teknoid <[EMAIL PROTECTED]> wrote:
>
> > > Can you show your use of containable?
> > > I think something might be amiss...
>
> > > On Nov 5, 6:21 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > > > After a bit of digging setting the 'recursive' property in the model
> > > > _partially_ solves this:
> > > > var $actsAs = array('Containable' => array('recursive' => false));
>
> > > > However, obviously won't help where some items need a 2nd or 3rd
> > > > level.
>
> > > > So I guess it comes back to: is there any way to be model-specific for
> > > > recursion?
>
> > > > On Nov 5, 2:54 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > > > > That's the problem with 'contain' though ... even if I do use a hasOne
> > > > > bind, 'contain&#x
Re: Finds: Contain vs. Unbind-on-the-fly
Aha!!!
I think I've come up with the reason ...
As I was trying to produce a nice a short example I realized that when
there's only 1 level it doesn't produce the extra queries ... as soon
as there's more than 1 level it has the extra queries.
So if I have:
$this->set('photographer',
$this->Photographer->find('first',
array('contain'
=> array(
'Country',
'State';
Then there's no problem, but if I have
$this->set('photographer',
$this->Photographer->find('first',
array('contain'
=> array(
'Country',
'State',
'PrintSize.PhotographersPrintSize';
Then it'll do extra queries on Country and State, in addition to
PrintSize and PhotographersPrintSize.
Even if I change it to
$this->set('photographer',
$this->Photographer->find('first',
array('contain'
=> array(
'Country',
'State',
'PrintSize' => array('PhotographersPrintSize');
I still run into the issue.
BTW:
class AppModel extends Model {
var $actsAs = array('Containable');
}
I suspect it's something to do with recursive, but will keep digging.
On Nov 6, 8:33 am, teknoid <[EMAIL PROTECTED]> wrote:
> Can you show your use of containable?
> I think something might be amiss...
>
> On Nov 5, 6:21 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > After a bit of digging setting the 'recursive' property in the model
> > _partially_ solves this:
> > var $actsAs = array('Containable' => array('recursive' => false));
>
> > However, obviously won't help where some items need a 2nd or 3rd
> > level.
>
> > So I guess it comes back to: is there any way to be model-specific for
> > recursion?
>
> > On Nov 5, 2:54 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > > That's the problem with 'contain' though ... even if I do use a hasOne
> > > bind, 'contain' will still do extra queries.
> > > In the example I mentioned, it will retrieve everything properly in 1
> > > big query, but then it'll go back again and find the models listed in
> > > 'contain'.
> > > On a default page of 20 records (since I'm doing pagination), where
> > > each record has 4 extra models to find you're looking at 80 extra
> > > unnecessary db hits ... multiply that by X users view the page and
> > > you're looking at a lot of unnecessary queries. Sure it's just
> > > milliseconds, but still quite concerning.
>
> > > On Nov 5, 2:48 pm, teknoid <[EMAIL PROTECTED]> wrote:
>
> > > > JOINS are only built for hasOne and belongsTo relationships.
> > > > A bunch of little selects will not harm your DB (how many milliseconds
> > > > do those queries take?)
>
> > > > Are you displaying some list on the page? Maybe paginate is in order
> > > > for this case?
>
> > > > All that being said, if you are not happy with that and prefer a long
> > > > JOIN query, you can always "trick" cake into building one, by using a
> > > > temporary hasOne bind.
>
> > > > On Nov 5, 5:08 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > > > > What might also help is a way to include recursion on only certain
> > > > > associations - which can be done with 'contain', but again, 'contain'
> > > > > is doing more db queries than it needs to.
>
> > > > > On Nov 5, 11:38 am, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > > > > > This is getting quite confusing/frustrating ...
>
> > > > > > If I use 'contain'
Re: Finds: Contain vs. Unbind-on-the-fly
After a bit of digging setting the 'recursive' property in the model
_partially_ solves this:
var $actsAs = array('Containable' => array('recursive' => false));
However, obviously won't help where some items need a 2nd or 3rd
level.
So I guess it comes back to: is there any way to be model-specific for
recursion?
On Nov 5, 2:54 pm, Brenton B <[EMAIL PROTECTED]> wrote:
> That's the problem with 'contain' though ... even if I do use a hasOne
> bind, 'contain' will still do extra queries.
> In the example I mentioned, it will retrieve everything properly in 1
> big query, but then it'll go back again and find the models listed in
> 'contain'.
> On a default page of 20 records (since I'm doing pagination), where
> each record has 4 extra models to find you're looking at 80 extra
> unnecessary db hits ... multiply that by X users view the page and
> you're looking at a lot of unnecessary queries. Sure it's just
> milliseconds, but still quite concerning.
>
> On Nov 5, 2:48 pm, teknoid <[EMAIL PROTECTED]> wrote:
>
> > JOINS are only built for hasOne and belongsTo relationships.
> > A bunch of little selects will not harm your DB (how many milliseconds
> > do those queries take?)
>
> > Are you displaying some list on the page? Maybe paginate is in order
> > for this case?
>
> > All that being said, if you are not happy with that and prefer a long
> > JOIN query, you can always "trick" cake into building one, by using a
> > temporary hasOne bind.
>
> > On Nov 5, 5:08 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > > What might also help is a way to include recursion on only certain
> > > associations - which can be done with 'contain', but again, 'contain'
> > > is doing more db queries than it needs to.
>
> > > On Nov 5, 11:38 am, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > > > This is getting quite confusing/frustrating ...
>
> > > > If I use 'contain' it's the equivalent of using 'unbind' (on the fly)
> > > > on everything not listed in 'contain' (as described in the Cookbook);
> > > > however, if I use 'contain', it seems to actually execute an extra
> > > > query to get that corresponding information, regardless of association
> > > > type.
>
> > > > For example, list of members with countries (belongsTo), provinces
> > > > (belongsTo), plus a whole bunch of other stuff: webpages, interests,
> > > > etc.
>
> > > > If I'm doing a listing, I just want name, country, and province, so I
> > > > can either do unbind on everything I don't need, or use 'contain' on
> > > > the things I do need 'contain' is the logical choice.
> > > > The resulting query does a LEFT JOIN on countries and provinces just
> > > > fine, but it ALSO does an extra query for every single country_id and
> > > > province_id to get the name. So on a big long list I'm getting quite a
> > > > few extra database hits.
>
> > > > Is this supposed to do this? Because it goes against the Cookbook's
> > > > comment of "Using Containable will help you cut down on needless wear
> > > > and tear on your database".
>
> > > > (This gets slightly worse once I go a level deeper.)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Finds: Contain vs. Unbind-on-the-fly
That's the problem with 'contain' though ... even if I do use a hasOne bind, 'contain' will still do extra queries. In the example I mentioned, it will retrieve everything properly in 1 big query, but then it'll go back again and find the models listed in 'contain'. On a default page of 20 records (since I'm doing pagination), where each record has 4 extra models to find you're looking at 80 extra unnecessary db hits ... multiply that by X users view the page and you're looking at a lot of unnecessary queries. Sure it's just milliseconds, but still quite concerning. On Nov 5, 2:48 pm, teknoid <[EMAIL PROTECTED]> wrote: > JOINS are only built for hasOne and belongsTo relationships. > A bunch of little selects will not harm your DB (how many milliseconds > do those queries take?) > > Are you displaying some list on the page? Maybe paginate is in order > for this case? > > All that being said, if you are not happy with that and prefer a long > JOIN query, you can always "trick" cake into building one, by using a > temporary hasOne bind. > > On Nov 5, 5:08 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > What might also help is a way to include recursion on only certain > > associations - which can be done with 'contain', but again, 'contain' > > is doing more db queries than it needs to. > > > On Nov 5, 11:38 am, Brenton B <[EMAIL PROTECTED]> wrote: > > > > This is getting quite confusing/frustrating ... > > > > If I use 'contain' it's the equivalent of using 'unbind' (on the fly) > > > on everything not listed in 'contain' (as described in the Cookbook); > > > however, if I use 'contain', it seems to actually execute an extra > > > query to get that corresponding information, regardless of association > > > type. > > > > For example, list of members with countries (belongsTo), provinces > > > (belongsTo), plus a whole bunch of other stuff: webpages, interests, > > > etc. > > > > If I'm doing a listing, I just want name, country, and province, so I > > > can either do unbind on everything I don't need, or use 'contain' on > > > the things I do need 'contain' is the logical choice. > > > The resulting query does a LEFT JOIN on countries and provinces just > > > fine, but it ALSO does an extra query for every single country_id and > > > province_id to get the name. So on a big long list I'm getting quite a > > > few extra database hits. > > > > Is this supposed to do this? Because it goes against the Cookbook's > > > comment of "Using Containable will help you cut down on needless wear > > > and tear on your database". > > > > (This gets slightly worse once I go a level deeper.) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Finds: Contain vs. Unbind-on-the-fly
What might also help is a way to include recursion on only certain associations - which can be done with 'contain', but again, 'contain' is doing more db queries than it needs to. On Nov 5, 11:38 am, Brenton B <[EMAIL PROTECTED]> wrote: > This is getting quite confusing/frustrating ... > > If I use 'contain' it's the equivalent of using 'unbind' (on the fly) > on everything not listed in 'contain' (as described in the Cookbook); > however, if I use 'contain', it seems to actually execute an extra > query to get that corresponding information, regardless of association > type. > > For example, list of members with countries (belongsTo), provinces > (belongsTo), plus a whole bunch of other stuff: webpages, interests, > etc. > > If I'm doing a listing, I just want name, country, and province, so I > can either do unbind on everything I don't need, or use 'contain' on > the things I do need 'contain' is the logical choice. > The resulting query does a LEFT JOIN on countries and provinces just > fine, but it ALSO does an extra query for every single country_id and > province_id to get the name. So on a big long list I'm getting quite a > few extra database hits. > > Is this supposed to do this? Because it goes against the Cookbook's > comment of "Using Containable will help you cut down on needless wear > and tear on your database". > > (This gets slightly worse once I go a level deeper.) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Finds: Contain vs. Unbind-on-the-fly
This is getting quite confusing/frustrating ... If I use 'contain' it's the equivalent of using 'unbind' (on the fly) on everything not listed in 'contain' (as described in the Cookbook); however, if I use 'contain', it seems to actually execute an extra query to get that corresponding information, regardless of association type. For example, list of members with countries (belongsTo), provinces (belongsTo), plus a whole bunch of other stuff: webpages, interests, etc. If I'm doing a listing, I just want name, country, and province, so I can either do unbind on everything I don't need, or use 'contain' on the things I do need 'contain' is the logical choice. The resulting query does a LEFT JOIN on countries and provinces just fine, but it ALSO does an extra query for every single country_id and province_id to get the name. So on a big long list I'm getting quite a few extra database hits. Is this supposed to do this? Because it goes against the Cookbook's comment of "Using Containable will help you cut down on needless wear and tear on your database". (This gets slightly worse once I go a level deeper.) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Ajax ObserField "Form is not defined"
I think I'm running into something similar with 1.2 and AJAX
submit ... however, could potentially be a compatibility issue with
Prototype.
On Sep 16, 4:51 am, AussieFreelancer <[EMAIL PROTECTED]>
wrote:
> anyone, anyone... does observeField actually work in 1.1? I have it
> working in 1.2 ok, but this project uses 1.1
>
> On Aug 5, 4:37 pm, AussieFreelancer <[EMAIL PROTECTED]>
> wrote:
>
> > Hi all, I am trying to get a chained select working using the code
> > found here: (5th post)
>
> >http://groups.google.com/group/cake-php/browse_thread/thread/b9eb6c15...
>
> > However when I run it, it doesn't work, and the error console tells me
> > that "Form is not defined". From looking at the source code, I can see
> > that the observeField has added the following code:
>
> > new
> > Form.Element.Observer('JobsCompanyId', 1, function(element, value)
> > {new Ajax.Updater('jobs_select_sites','/sites/ajax_sites/',
> > {asynchronous:true, evalScripts:true,
> > parameters:Form.Element.serialize('JobsCompanyId'), requestHeaders:['X-
> > Update', 'jobs_select_sites']})})
>
> > So I can see where the Form bit comes from, but am unsure as to why it
> > is undefined. I have added theprototypeand scriptaculous libs to /
> > app/webroot/js and included them in the page head.
>
> > I am using 1.1 for this project, and would love to have this working,
> > as this is just the start of the chained select development (I have 3
> > multiple select boxes)
>
> > Any help someone can offer would be hugely appreciated.
>
> > Thanks
>
> > Patrick
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: In Some Controllers app_controller is not extending
Just a heads up, for starters, the app_controller.php file is best placed in `\app\app_controller.php` rather than the Cake libraries because if/when you go to upgrade it'll get over-written. How is the "code for changing page name" called? in `beforeFilter()`? or elsewhere? If it's something common like `beforeFilter()` make sure that your child classes are calling the proper parent function, ex: `parent::beforeFilter();` On Nov 4, 12:51 am, Jipson <[EMAIL PROTECTED]> wrote: > Hi All, > In my cakephp project Page title, meta name and description are > stored in a table in database. > in my Cart\cake\libs\controller folder app_controller.php file is > there. In that file I wrote code for changing page name.In some > controllers I am not getting the page title. can anyone please help > me? > > Thanks in advance > Jipaon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Confusion with $uniqueIds in dbo_source.php
Still no love, hey? I'm not sure how else to explain this other than to ask why dbo_source.php is over-writing. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Paginator: sort + limit saved to session.
github.com webpage isn't working either. On Nov 3, 4:24 pm, Brenton B <[EMAIL PROTECTED]> wrote: > Hmm ... that looks familiar and I had stumbled upon it while looking, > but figured it might've been taken down for some reason. > Cheers. > > On Nov 3, 3:28 pm, MattC <[EMAIL PROTECTED]> wrote: > > > I think you're talking about one I > > wrote:http://bakery.cakephp.org/articles/view/pagination-recall > > > Article seems messed up at the moment. Code is also available > > at:http://github.com/mcurry/cakephp/tree/master/components/pagination_re... > > > I haven't checked this code in a while so if there are any issues w/ > > RC3 let me know. > > > -Mattwww.pseudocoder.com > > > On Nov 3, 6:16 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > > I remember coming across a component of some sort that saves the sort > > > and "per page" variables to session and thus recalls them when need > > > be, except I can't seem to find it won't be too hard to recreate > > > but would rather not re-invent the wheel. > > > For the life of me I'm coming up dry, all searches have come up empty, > > > anyone have it? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Paginator: sort + limit saved to session.
Hmm ... that looks familiar and I had stumbled upon it while looking, but figured it might've been taken down for some reason. Cheers. On Nov 3, 3:28 pm, MattC <[EMAIL PROTECTED]> wrote: > I think you're talking about one I > wrote:http://bakery.cakephp.org/articles/view/pagination-recall > > Article seems messed up at the moment. Code is also available > at:http://github.com/mcurry/cakephp/tree/master/components/pagination_re... > > I haven't checked this code in a while so if there are any issues w/ > RC3 let me know. > > -Mattwww.pseudocoder.com > > On Nov 3, 6:16 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > I remember coming across a component of some sort that saves the sort > > and "per page" variables to session and thus recalls them when need > > be, except I can't seem to find it won't be too hard to recreate > > but would rather not re-invent the wheel. > > For the life of me I'm coming up dry, all searches have come up empty, > > anyone have it? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Paginator: sort + limit saved to session.
I remember coming across a component of some sort that saves the sort and "per page" variables to session and thus recalls them when need be, except I can't seem to find it won't be too hard to recreate but would rather not re-invent the wheel. For the life of me I'm coming up dry, all searches have come up empty, anyone have it? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Multiple table conditions HABTM
http://bakery.cakephp.org/articles/view/habtm-searching
On Oct 15, 9:47 am, [EMAIL PROTECTED] wrote:
> I am a worker for this grouped i am sorry i clicked the worng post.
>
> On 10/15/2008, Brenton B <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > Huh? This specific discussion, or the group itself?
> > Probably because at some point you signed up to follow this
> > discussion, can always remove yourself from it and edit your profile
> > to no longer receive updates.
>
> > On Oct 14, 4:59 pm, [EMAIL PROTECTED] wrote:
> >> This keeps on show up in my email. The subject. I was wondering what
> >> this was for?
>
> >> On 10/14/2008, Brenton B <[EMAIL PROTECTED]> wrote:
>
> >> > Not sure if this is close to what you need,
> >> >http://www.bbartel.ca/blog/brenton/2008/oct/14/habtm-searching
> >> > (will touch up formatting shortly).
>
> >> > On Oct 14, 3:16 am, hariharan <[EMAIL PROTECTED]> wrote:
> >> >> I am also stuck with the same problem . For HABTM or hasMany it doesnt
> >> >> query with join. rather queries each and every table in an individual
> >> >> manner, which is time consuming one.
>
> >> >> Another thing is cakephp does not support through association like
> >> >> ROR. suppose if I have two HABTM then i cant access the fields of the
> >> >> extra table formed due to the relationships.
>
> >> >> eg user and group
>
> >> >> users -> HASMANYANDBELONGSTO -> groups
> >> >> groups -> HASMANYANDBELONGSTO -> users
>
> >> >> so the other table result due to this is groups_users. other than
> >> >> group_id and user_id suppose if i want to store additional info such
> >> >> as when did they joined group etc... i cant access those fields.
>
> >> >> help me.
>
> >> >> On Oct 8, 1:56 am, jmmg77 <[EMAIL PROTECTED]> wrote:
>
> >> >> > Okay,
>
> >> >> > Whenever I have a hasOne or belongsTo association, those models are
> >> >> > included in the query whenever I do a find('all');
>
> >> >> > But, when I have any other type of association, find('all' only
> >> >> > generates a query with the model I'm searching.
> >> >> > This keeps me from filtering by fields in the related models.
>
> >> >> > ex:
> >> >> > $funnypeople = $this->Individual->find('all', array('conditions' =>
> >> >> > array('Personality.type' => 3)));
>
> >> >> > This example works find if a person only has one Personality Type.
> >> >> > But what about this.
>
> >> >> > $racecardrivers = $this->Individual->find('all', array('conditions'
> >> >> > =>
> >> >> > array('Vehicle.type' => 2)));
>
> >> >> > The problem here is a person could own multiple vehicles, so
> >> >> > belongsTo
> >> >> > & hasOne don't work here.
> >> >> > I would need hasMany or hasAndBelongsToMany, which makes those model
> >> >> > inaccessible using find.
>
> >> >> > Any help would be greatly appreciated. Thanks.
>
> >> --
> >> Xavier A. Mathews
> >> Student/Developer/Web-Master
> >> GG Client Based Tech Support Specialist
> >> Hazel Crest Illinois
> >> [EMAIL PROTECTED]
> >> "Fear of a name, only increases fear of the thing itself."
>
> --
> Xavier A. Mathews
> Student/Developer/Web-Master
> GG Client Based Tech Support Specialist
> Hazel Crest Illinois
> [EMAIL PROTECTED]
> "Fear of a name, only increases fear of the thing itself."
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: HABTM goodness: searching!!
http://bakery.cakephp.org/articles/view/habtm-searching On Oct 14, 4:56 pm, Brenton B <[EMAIL PROTECTED]> wrote: > In the mean time: > > http://www.bbartel.ca/blog/brenton/2008/oct/14/habtm-searching > > Please forgive the horrible formatting, not sure what's going on > there, and don't have time right now to figure it out. > > On Oct 14, 4:43 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > Stay tuned for article ... pending publication approval in the Bakery. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Admin + Members suggested setup??
Thanks everyone for the useful tips, that helps a lot, which means I may have to restructure some stuff. Mostly, I think I was getting confused by the fact that with having `index` and `admin_index` I ended up doing 2 different views, where the difference was only whether or not to include an 'edit' link in the list ... which all seemed redundant, because any small change I'd make to one, I'd have to make to the other and seemed a bit more efficient to have a single view with checks for if they have permission or not. Cheers On Oct 31, 1:49 am, Adam Royle <[EMAIL PROTECTED]> wrote: > Admin routing as more useful in a CMS-style site where there are > clearly two distinct areas display of site data, and administering > site data, which both could differ greatly in controller & view code, > rather than just acl & permissions. > > Hope that clears things up. > > Cheers, > Adam > > On Oct 29, 6:33 am, Brenton B <[EMAIL PROTECTED]> wrote: > > > Quick question as to what would be the best Cake-y setup: > > > So I've got a list of Users who can either be Admin, Editors, or > > simply Members. > > Members can edit their own profiles, but Admin can also edit anyone's > > profile (at this point Editors are just normal Members with special > > status). > > > When it comes to admin routing, should that only be used for strictly > > Admins and not Members? > > Ex: > > /profiles/edit -> what Members use and there's a check that the > > profile matches with the member > > /profiles/admin_edit -> only Admin uses this. > > > And how would that all work with ACL? It seems like there's a wee bit > > of overlap here. > > > How have people set this up? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Admin + Members suggested setup??
Is the Admin routing intended as strictly for Root Admin? Or anyone that can log in? just seems a bit vague. On Oct 29, 11:54 am, Brenton B <[EMAIL PROTECTED]> wrote: > Essentially ... what makes the Admin Routing so special, and why > should I use it? What's the advantage over just having all the checks > in my own code? (ex: checks that they're logged in as admin and have > the right permissions) > > On Oct 28, 1:33 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > Quick question as to what would be the best Cake-y setup: > > > So I've got a list of Users who can either be Admin, Editors, or > > simply Members. > > Members can edit their own profiles, but Admin can also edit anyone's > > profile (at this point Editors are just normal Members with special > > status). > > > When it comes to admin routing, should that only be used for strictly > > Admins and not Members? > > Ex: > > /profiles/edit -> what Members use and there's a check that the > > profile matches with the member > > /profiles/admin_edit -> only Admin uses this. > > > And how would that all work with ACL? It seems like there's a wee bit > > of overlap here. > > > How have people set this up? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Admin + Members suggested setup??
Essentially ... what makes the Admin Routing so special, and why should I use it? What's the advantage over just having all the checks in my own code? (ex: checks that they're logged in as admin and have the right permissions) On Oct 28, 1:33 pm, Brenton B <[EMAIL PROTECTED]> wrote: > Quick question as to what would be the best Cake-y setup: > > So I've got a list of Users who can either be Admin, Editors, or > simply Members. > Members can edit their own profiles, but Admin can also edit anyone's > profile (at this point Editors are just normal Members with special > status). > > When it comes to admin routing, should that only be used for strictly > Admins and not Members? > Ex: > /profiles/edit -> what Members use and there's a check that the > profile matches with the member > /profiles/admin_edit -> only Admin uses this. > > And how would that all work with ACL? It seems like there's a wee bit > of overlap here. > > How have people set this up? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Admin + Members suggested setup??
Quick question as to what would be the best Cake-y setup: So I've got a list of Users who can either be Admin, Editors, or simply Members. Members can edit their own profiles, but Admin can also edit anyone's profile (at this point Editors are just normal Members with special status). When it comes to admin routing, should that only be used for strictly Admins and not Members? Ex: /profiles/edit -> what Members use and there's a check that the profile matches with the member /profiles/admin_edit -> only Admin uses this. And how would that all work with ACL? It seems like there's a wee bit of overlap here. How have people set this up? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Multiple table conditions HABTM
Huh? This specific discussion, or the group itself?
Probably because at some point you signed up to follow this
discussion, can always remove yourself from it and edit your profile
to no longer receive updates.
On Oct 14, 4:59 pm, [EMAIL PROTECTED] wrote:
> This keeps on show up in my email. The subject. I was wondering what
> this was for?
>
> On 10/14/2008, Brenton B <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > Not sure if this is close to what you need,
> >http://www.bbartel.ca/blog/brenton/2008/oct/14/habtm-searching
> > (will touch up formatting shortly).
>
> > On Oct 14, 3:16 am, hariharan <[EMAIL PROTECTED]> wrote:
> >> I am also stuck with the same problem . For HABTM or hasMany it doesnt
> >> query with join. rather queries each and every table in an individual
> >> manner, which is time consuming one.
>
> >> Another thing is cakephp does not support through association like
> >> ROR. suppose if I have two HABTM then i cant access the fields of the
> >> extra table formed due to the relationships.
>
> >> eg user and group
>
> >> users -> HASMANYANDBELONGSTO -> groups
> >> groups -> HASMANYANDBELONGSTO -> users
>
> >> so the other table result due to this is groups_users. other than
> >> group_id and user_id suppose if i want to store additional info such
> >> as when did they joined group etc... i cant access those fields.
>
> >> help me.
>
> >> On Oct 8, 1:56 am, jmmg77 <[EMAIL PROTECTED]> wrote:
>
> >> > Okay,
>
> >> > Whenever I have a hasOne or belongsTo association, those models are
> >> > included in the query whenever I do a find('all');
>
> >> > But, when I have any other type of association, find('all' only
> >> > generates a query with the model I'm searching.
> >> > This keeps me from filtering by fields in the related models.
>
> >> > ex:
> >> > $funnypeople = $this->Individual->find('all', array('conditions' =>
> >> > array('Personality.type' => 3)));
>
> >> > This example works find if a person only has one Personality Type.
> >> > But what about this.
>
> >> > $racecardrivers = $this->Individual->find('all', array('conditions' =>
> >> > array('Vehicle.type' => 2)));
>
> >> > The problem here is a person could own multiple vehicles, so belongsTo
> >> > & hasOne don't work here.
> >> > I would need hasMany or hasAndBelongsToMany, which makes those model
> >> > inaccessible using find.
>
> >> > Any help would be greatly appreciated. Thanks.
>
> --
> Xavier A. Mathews
> Student/Developer/Web-Master
> GG Client Based Tech Support Specialist
> Hazel Crest Illinois
> [EMAIL PROTECTED]
> "Fear of a name, only increases fear of the thing itself."
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Multiple table conditions HABTM
Not sure if this is close to what you need,
http://www.bbartel.ca/blog/brenton/2008/oct/14/habtm-searching
(will touch up formatting shortly).
On Oct 14, 3:16 am, hariharan <[EMAIL PROTECTED]> wrote:
> I am also stuck with the same problem . For HABTM or hasMany it doesnt
> query with join. rather queries each and every table in an individual
> manner, which is time consuming one.
>
> Another thing is cakephp does not support through association like
> ROR. suppose if I have two HABTM then i cant access the fields of the
> extra table formed due to the relationships.
>
> eg user and group
>
> users -> HASMANYANDBELONGSTO -> groups
> groups -> HASMANYANDBELONGSTO -> users
>
> so the other table result due to this is groups_users. other than
> group_id and user_id suppose if i want to store additional info such
> as when did they joined group etc... i cant access those fields.
>
> help me.
>
> On Oct 8, 1:56 am, jmmg77 <[EMAIL PROTECTED]> wrote:
>
> > Okay,
>
> > Whenever I have a hasOne or belongsTo association, those models are
> > included in the query whenever I do a find('all');
>
> > But, when I have any other type of association, find('all' only
> > generates a query with the model I'm searching.
> > This keeps me from filtering by fields in the related models.
>
> > ex:
> > $funnypeople = $this->Individual->find('all', array('conditions' =>
> > array('Personality.type' => 3)));
>
> > This example works find if a person only has one Personality Type.
> > But what about this.
>
> > $racecardrivers = $this->Individual->find('all', array('conditions' =>
> > array('Vehicle.type' => 2)));
>
> > The problem here is a person could own multiple vehicles, so belongsTo
> > & hasOne don't work here.
> > I would need hasMany or hasAndBelongsToMany, which makes those model
> > inaccessible using find.
>
> > Any help would be greatly appreciated. Thanks.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: HABTM goodness: searching!!
In the mean time: http://www.bbartel.ca/blog/brenton/2008/oct/14/habtm-searching Please forgive the horrible formatting, not sure what's going on there, and don't have time right now to figure it out. On Oct 14, 4:43 pm, Brenton B <[EMAIL PROTECTED]> wrote: > Stay tuned for article ... pending publication approval in the Bakery. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: HABTM goodness: searching!!
Stay tuned for article ... pending publication approval in the Bakery. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Multiple table conditions HABTM
What kind of SQL errors, if any, are being thrown?
On Oct 14, 3:16 am, hariharan <[EMAIL PROTECTED]> wrote:
> I am also stuck with the same problem . For HABTM or hasMany it doesnt
> query with join. rather queries each and every table in an individual
> manner, which is time consuming one.
>
> Another thing is cakephp does not support through association like
> ROR. suppose if I have two HABTM then i cant access the fields of the
> extra table formed due to the relationships.
>
> eg user and group
>
> users -> HASMANYANDBELONGSTO -> groups
> groups -> HASMANYANDBELONGSTO -> users
>
> so the other table result due to this is groups_users. other than
> group_id and user_id suppose if i want to store additional info such
> as when did they joined group etc... i cant access those fields.
>
> help me.
>
> On Oct 8, 1:56 am, jmmg77 <[EMAIL PROTECTED]> wrote:
>
> > Okay,
>
> > Whenever I have a hasOne or belongsTo association, those models are
> > included in the query whenever I do a find('all');
>
> > But, when I have any other type of association, find('all' only
> > generates a query with the model I'm searching.
> > This keeps me from filtering by fields in the related models.
>
> > ex:
> > $funnypeople = $this->Individual->find('all', array('conditions' =>
> > array('Personality.type' => 3)));
>
> > This example works find if a person only has one Personality Type.
> > But what about this.
>
> > $racecardrivers = $this->Individual->find('all', array('conditions' =>
> > array('Vehicle.type' => 2)));
>
> > The problem here is a person could own multiple vehicles, so belongsTo
> > & hasOne don't work here.
> > I would need hasMany or hasAndBelongsToMany, which makes those model
> > inaccessible using find.
>
> > Any help would be greatly appreciated. Thanks.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: HABTM goodness: searching!!
Yeah, that is an odd suggestion, but such is life. ;) Once I polish up my code I will be posting it, because clearly HABTM has some of ironing out to do if there are umpteen posts about it. This was a fun discussion, wasn't it? Disclaimer: I'm not knocking Cake as a whole, just some areas need some clarification ... which is expect for a framework at this stage in it's development. On Oct 14, 12:12 pm, AD7six <[EMAIL PROTECTED]> wrote: > On Oct 14, 8:57 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > > > Ooh, you mean "HABTM" in the _Cook_ book??? oooh, I see what > > you're saying now, that makes so much sense!! I can't believe I never > > read the tutorials to start with. How foolish of me not to have > > searched through everything. > > > /sarcasm > > > Sorry ... just had to get that out. > > > Please read beyond the title of the discussion. > > I know I didn't give any specifics of what I'm trying to do, because > > I've got quite a few different scenarios all of which are quite > > complex and I'm looking for a nice fancy component to handle > > searching ... wherein "hackery" and "trickery" are not in the > > description. As an example, (using auto mechanics) I shouldn't have to > > duct tape my muffler because the crazy glue is melting. > > > No worries though, because I couldn't find anything I've developed my > > own chunk of code to handle it ... I just wanted to see if there pre- > > existed anything in the wild before re-inventing it. > > Forgive me for suggesting you'd need to know/learn how to solve it > once, to be able to solve it for all. Odd suggestion I know. > > Glad to hear you solved your problem - you are the umpteenth person to > post to the group regarding habtm searching and you won't be the last > - why don't you post your solution somewhere, or add it to the bakery > for future reference. > > Cheers, > > AD --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: HABTM goodness: searching!!
Ooh, you mean "HABTM" in the _Cook_ book??? oooh, I see what you're saying now, that makes so much sense!! I can't believe I never read the tutorials to start with. How foolish of me not to have searched through everything. /sarcasm Sorry ... just had to get that out. Please read beyond the title of the discussion. I know I didn't give any specifics of what I'm trying to do, because I've got quite a few different scenarios all of which are quite complex and I'm looking for a nice fancy component to handle searching ... wherein "hackery" and "trickery" are not in the description. As an example, (using auto mechanics) I shouldn't have to duct tape my muffler because the crazy glue is melting. No worries though, because I couldn't find anything I've developed my own chunk of code to handle it ... I just wanted to see if there pre- existed anything in the wild before re-inventing it. On Oct 14, 11:22 am, AD7six <[EMAIL PROTECTED]> wrote: > On Oct 14, 8:17 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > There is nothing in the Cookbook about the "joins" key. Once martin > > mentioned it I double checked. I then searched the code itself > > (dbo_source.php) and lo-and-behold, it does exist. I have yet to take > > a look and experiment to see what it does though. > > > Sorry if I hurt your feelings by venting that Cake isn't too popular > > with me right now. > > Heh my feelings are fine. I'll be even more obvious given your reply. > > Open book.cakephp.org, type "habtm" in the search box and read the > *whole* section. There are a number of examples of how to do exactly > what you're asking. > > So given it's the first result in the first place to look for info; I > don't think it's inappropriate spoon feed that info. > > AD --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: HABTM goodness: searching!!
There is nothing in the Cookbook about the "joins" key. Once martin mentioned it I double checked. I then searched the code itself (dbo_source.php) and lo-and-behold, it does exist. I have yet to take a look and experiment to see what it does though. Sorry if I hurt your feelings by venting that Cake isn't too popular with me right now. Thanks again martin for the tip about the "joins" key, hopefully someone else will find it useful as well. On Oct 14, 9:24 am, AD7six <[EMAIL PROTECTED]> wrote: > On Oct 14, 11:38 am, Brenton B <[EMAIL PROTECTED]> wrote: > > > H ... will take a look, cheers. > > Or look inthe book habtm section (should have been pit stop 1) or > search the group (should have been pit stop 2) > > Ironic that searching is the topic and is the thing that's missing. > > AD --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: HABTM goodness: searching!!
H ... will take a look, cheers. On Oct 14, 12:04 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > If it is joins you are after, check out the "joins" key that you can > add to queries. It is not documented much yet (because it is rarely > needed) but it could be just what you need. > > I have had to set up a special type of search query and ended up > creating my own function to handle my not so common search needs. > I put it in the bin a while back. You can take a look at it to see > "joins" in action. In that class the joins are used to create a big > join with all the classes "belongsTo" associations and be able to pick > out statistics in a "StarSchema" kind of way (aka OLAP, sort of). > > It is not exactly ready for public release but I was hoping someone > would get something out of looking at the code. > > /Martin > > On Oct 14, 4:50 am, Brenton B <[EMAIL PROTECTED]> wrote: > > > Indeed. > > > On Oct 12, 3:49 am, AD7six <[EMAIL PROTECTED]> wrote: > > > > On Oct 11, 11:41 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > > > Out of frustration: hate to say it, but Cake is quickly dropping on my > > > > list of "usable frameworks" due to it's inability to efficiently > > > > handle joins. > > > > Oh well. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: HABTM goodness: searching!!
Indeed. On Oct 12, 3:49 am, AD7six <[EMAIL PROTECTED]> wrote: > On Oct 11, 11:41 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > Out of frustration: hate to say it, but Cake is quickly dropping on my > > list of "usable frameworks" due to it's inability to efficiently > > handle joins. > > Oh well. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: HABTM goodness: searching!!
Out of frustration: hate to say it, but Cake is quickly dropping on my
list of "usable frameworks" due to it's inability to efficiently
handle joins.
On Oct 8, 1:24 pm, Brenton B <[EMAIL PROTECTED]> wrote:
> I feel like I'm spinning my wheels searching for something that I
> woulda figured was already coded, but no such luck ... I'm looking for
> something that helps with searching on any possible association setup
> for a Model. So of the stuff I've come across are:
>
> http://nik.chankov.net/2008/03/01/filtering-component-for-your-tables/http://teknoid.wordpress.com/2008/08/06/habtm-and-join-trickery-with-...http://bakery.cakephp.org/articles/view/advanced-pagination-1-2
> ("Search" portion)
> Items in the Google Group FAQ.
>
> But so far nothing the encompasses it all, the "Containable" behaviour
> doesn't even quite do it - close, but not constraining enough.
> Furthermore, some of the solutions involve having to do it over again
> for each Model/Controller that requires, or have "trickery" or
> "hackery" - not that that's necessarily "bad", just having to do a
> "work around" is indicative of an underlying fault or missing feature.
>
> So my question is: does anyone have a nifty little component that
> handles this all?
>
> I'll probably just write my own, but worth checking before re-
> inventing the wheel.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Confusion with $uniqueIds in dbo_source.php
You're missing the point. Don't worry. On Oct 11, 6:55 am, villas <[EMAIL PROTECTED]> wrote: > Hi Brenton > > I think we need help from a HABTM expert :-) > > From what I understand, storing extra info in the join table is > commonly done. However, I think storing multiple join table rows for > the same join so that you can store even more data is going beyond the > existing HABTM design. > > Technically speaking, I guess you ought to create an extra table and > then make a three-way join which I've heard some people call > 'ternary'. > > I believe you would make extra models and associations depending on > how you need to manage the data. This thread may > help:http://groups.google.com/group/cake-php/browse_frm/thread/7ee52fa005d... > > Best wishes > > On Oct 11, 10:21 am, Brenton B <[EMAIL PROTECTED]> wrote: > > > Hey villas, > > > Thanks for that. > > I had read through a bunch of those and I have put in the ID field and > > experimented with the 'unique' functionality but was still confused > > why the core is restricting potentially useful rows. The logic in that > > chunk of code doesn't seem to fit. I mean if the result from the query > > is the reason for looping through it and stripping out duplicates, > > then obviously there's something faulty with returning duplicates. > > It's quite inefficient as well, regardless if we're talking about > > fractions of seconds, inefficiency is inefficiency. > > I'm just saying at first glance it seems like a band-aid solution to a > > (currently unknown) problem. > > > On Oct 10, 3:29 pm, villas <[EMAIL PROTECTED]> wrote: > > > > Hi Brenton, > > > > Saving extra fields in the join table has been discussed a few times > > > in the group. > > > > From what I understand, it seems you should add an ID field to the > > > join table and then start accessing the join table through models in > > > other ways than simply relying on the basic HABTM functionality. > > > Reading these links might help: > > > >http://groups.google.com/group/cake-php/browse_thread/thread/bf91d27a.. > > > See Mariano's article: tinyurl.com/4kbe9q > > > > I also notice you are using the default 'unique' => true in your > > > setup. Maybe you should also consider experimenting with that because > > > it overwrites previous entries but I'm not sure if it's relevant to > > > your situation. For ease of reference, the book section describing > > > this is here:http://book.cakephp.org/view/83/hasAndBelongsToMany-HABTM > > > > Hope this helps a little. > > > > On Oct 10, 10:26 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > > > Basically, on a HABTM relationship, it's not returning all rows > > > > because it's filtering out for unique ids ... why?!?! > > > > > In my mind, it's not logical to eliminate valid rows when returning > > > > them, there's no comments explaining why this is being done so I'm > > > > asking here. > > > > I ran into an issue where I want rows because that's what HABTM is > > > > supposed to do, but it's not ... > > > > > Not sure how else i can explain it ... > > > > > PS. See link to original discussion. > > > > > On Oct 10, 2:01 pm, Gwoo <[EMAIL PROTECTED]> wrote: > > > > > > You have not provided enough information for anyone to help. You need > > > > > to say what you are expecting, show the results of that. Pasting core > > > > > code is not of any help without that information. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Confusion with $uniqueIds in dbo_source.php
Hey villas, Thanks for that. I had read through a bunch of those and I have put in the ID field and experimented with the 'unique' functionality but was still confused why the core is restricting potentially useful rows. The logic in that chunk of code doesn't seem to fit. I mean if the result from the query is the reason for looping through it and stripping out duplicates, then obviously there's something faulty with returning duplicates. It's quite inefficient as well, regardless if we're talking about fractions of seconds, inefficiency is inefficiency. I'm just saying at first glance it seems like a band-aid solution to a (currently unknown) problem. On Oct 10, 3:29 pm, villas <[EMAIL PROTECTED]> wrote: > Hi Brenton, > > Saving extra fields in the join table has been discussed a few times > in the group. > > From what I understand, it seems you should add an ID field to the > join table and then start accessing the join table through models in > other ways than simply relying on the basic HABTM functionality. > Reading these links might help: > > http://groups.google.com/group/cake-php/browse_thread/thread/bf91d27a...http://groups.google.com/group/cake-php/browse_thread/thread/4505a4ca... > See Mariano's article: tinyurl.com/4kbe9q > > I also notice you are using the default 'unique' => true in your > setup. Maybe you should also consider experimenting with that because > it overwrites previous entries but I'm not sure if it's relevant to > your situation. For ease of reference, the book section describing > this is here:http://book.cakephp.org/view/83/hasAndBelongsToMany-HABTM > > Hope this helps a little. > > On Oct 10, 10:26 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > Basically, on a HABTM relationship, it's not returning all rows > > because it's filtering out for unique ids ... why?!?! > > > In my mind, it's not logical to eliminate valid rows when returning > > them, there's no comments explaining why this is being done so I'm > > asking here. > > I ran into an issue where I want rows because that's what HABTM is > > supposed to do, but it's not ... > > > Not sure how else i can explain it ... > > > PS. See link to original discussion. > > > On Oct 10, 2:01 pm, Gwoo <[EMAIL PROTECTED]> wrote: > > > > You have not provided enough information for anyone to help. You need > > > to say what you are expecting, show the results of that. Pasting core > > > code is not of any help without that information. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Confusion with $uniqueIds in dbo_source.php
Basically, on a HABTM relationship, it's not returning all rows because it's filtering out for unique ids ... why?!?! In my mind, it's not logical to eliminate valid rows when returning them, there's no comments explaining why this is being done so I'm asking here. I ran into an issue where I want rows because that's what HABTM is supposed to do, but it's not ... Not sure how else i can explain it ... PS. See link to original discussion. On Oct 10, 2:01 pm, Gwoo <[EMAIL PROTECTED]> wrote: > You have not provided enough information for anyone to help. You need > to say what you are expecting, show the results of that. Pasting core > code is not of any help without that information. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Confusion with $uniqueIds in dbo_source.php
Perhaps there's a better place to ask this since no one seems to be
answering it?
On Oct 8, 6:22 pm, Brenton B <[EMAIL PROTECTED]> wrote:
> So ... no one knows, hey? shucks.
>
> On Oct 7, 2:58 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > Why are we restricting rows in dbo_source.php on 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);
> > }
> > }
>
> > Original discussion started
> > inhttp://groups.google.com/group/cake-php/browse_thread/thread/25341f4a...
> > A new discussion was opened since this topic has deviated from the
> > original discussion.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Confusion with $uniqueIds in dbo_source.php
So ... no one knows, hey? shucks.
On Oct 7, 2:58 pm, Brenton B <[EMAIL PROTECTED]> wrote:
> Why are we restricting rows in dbo_source.php on 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);
> }
> }
>
> Original discussion started
> inhttp://groups.google.com/group/cake-php/browse_thread/thread/25341f4a...
> A new discussion was opened since this topic has deviated from the
> original discussion.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Another HABTM issue : row with same Id getting over-written
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 &qu
HABTM goodness: searching!!
I feel like I'm spinning my wheels searching for something that I
woulda figured was already coded, but no such luck ... I'm looking for
something that helps with searching on any possible association setup
for a Model. So of the stuff I've come across are:
http://nik.chankov.net/2008/03/01/filtering-component-for-your-tables/
http://teknoid.wordpress.com/2008/08/06/habtm-and-join-trickery-with-cakephp/
http://bakery.cakephp.org/articles/view/advanced-pagination-1-2
("Search" portion)
Items in the Google Group FAQ.
But so far nothing the encompasses it all, the "Containable" behaviour
doesn't even quite do it - close, but not constraining enough.
Furthermore, some of the solutions involve having to do it over again
for each Model/Controller that requires, or have "trickery" or
"hackery" - not that that's necessarily "bad", just having to do a
"work around" is indicative of an underlying fault or missing feature.
So my question is: does anyone have a nifty little component that
handles this all?
I'll probably just write my own, but worth checking before re-
inventing the wheel.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Confusion with $uniqueIds in dbo_source.php
Why are we restricting rows in dbo_source.php on 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);
}
}
Original discussion started in
http://groups.google.com/group/cake-php/browse_thread/thread/25341f4a28e69db7
A new discussion was opened since this topic has deviated from the
original discussion.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Bi-directional HABTM edits getting deleted.
Setup: Categories HABTM Tags ... and consequently Tags HABTM Categories .. join table: categories_tags. I've got the forms setup working for both ways: Categories has a list of Tags; and Tags has a list of Categories. Unfortunately, since the way to update one or the other is to do a complete DELETE on the corresponding foreign key, then add anything that's new. So if I go and create a Category and select a bunch of Tags ... then I go into one of the Tags and edit something in there, it wipes 'em all and adds 'em (as expected), but information is lost. Now, if I add an `id` on the `categories_tags` table, then everything that needs to be is retained; however, since it's still doing a DELETE then INSERT, my `id` goes up every time I do save an edit ... thus possibly resulting in a really high `id`. So I guess there's no way around it. doh!! (This is mostly an info blurb for any other newbies who are confused). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Another HABTM issue : row with same Id getting over-written
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 someth
Re: Another HABTM issue : row with same Id getting over-written
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 you
Re: Another HABTM issue : row with same Id getting over-written
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 thi
Re: find('list') + "contain" option.
Aha!!
That would do it ... in the `find()` call, I just threw in
`'recursive' => 1,` and all is hunky dory now.
Thanks a bunch AD.
PS. Sorry if my tone was rude, not my intention, just being cheeky ;)
On Oct 6, 12:11 pm, AD7six <[EMAIL PROTECTED]> wrote:
> On Oct 6, 8:44 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
>
>
> > uh ... k ...
>
> > So for models there's the "find" function, whose first parameter can
> > be an assortment of strings depending on what you want to find ...
> > well, one of the ones I'm using is "list", which will generate a list
> > that's for easier usage in a select list.
> > Then there's also the possibility of an array of options as the second
> > parameter. One of these possible options is the "contain" key, which,
> > when used, would denote what associations to use while doing the find.
> > This option doesn't seem to take affect when I use it in conjunction
> > with `find('list')`.
> > Another thing you an do with the second 'options' array parameter is
> > declare how you want the list returned, and what it is to be grouped
> > by, for the select list.
>
> > In my case, I have a list of States ... I want them grouped by Country
> > name Therefore, I'm calling it like this:
>
> > $states = $this->User->State->find('list',
> >
> > array('contain' => array('Country'),
> >
> > 'fields' => array('State.id', 'State.name', 'Country.name')
> > ));
>
> > However, it barks and complains that "Warning (512): SQL Error: 1054:
> > Unknown column 'Country.name' in 'field list'", which is because
> > 'Country' isn't included int he query ("Query: SELECT `State`.`id`,
> > `State`.`name`, `Country`.`name` FROM `states` AS `State` WHERE 1 =
> > 1 ORDER BY `State`.`name` ASC "), because (I'm assuming) "contain"
> > does not work.
>
> > If I do `find('all')` (with everything else being the same), it
> > returns without error ... albeit, completely screwed up for the select
> > list if I do 'State.country_id' for the "group" field (3rd in the
> > 'fields' array), it returns without error, albeit using the id and not
> > the name for the group.
>
> > Details added.
>
> > Confused or understood?
>
> Apparently you weren't expecting a reply in the same tone as the
> question.
> Is this on purpose?
>
> Find list has a default recursive level of
> -1https://trac.cakephp.org/browser/branches/1.2.x.x/cake/libs/model/mod...
>
> AD
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: find('list') + "contain" option.
Sure do ... but no love.
On Oct 6, 12:05 pm, majna <[EMAIL PROTECTED]> wrote:
> Example:http://teknoid.wordpress.com/2008/09/05/example-of-cakephps-containab...
> Do you have Containable behavior included in model (var $actsAs =
> array('Containable');) ?
>
> On Oct 6, 8:44 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > uh ... k ...
>
> > So for models there's the "find" function, whose first parameter can
> > be an assortment of strings depending on what you want to find ...
> > well, one of the ones I'm using is "list", which will generate a list
> > that's for easier usage in a select list.
> > Then there's also the possibility of an array of options as the second
> > parameter. One of these possible options is the "contain" key, which,
> > when used, would denote what associations to use while doing the find.
> > This option doesn't seem to take affect when I use it in conjunction
> > with `find('list')`.
> > Another thing you an do with the second 'options' array parameter is
> > declare how you want the list returned, and what it is to be grouped
> > by, for the select list.
>
> > In my case, I have a list of States ... I want them grouped by Country
> > name Therefore, I'm calling it like this:
>
> > $states = $this->User->State->find('list',
> >
> > array('contain' => array('Country'),
> >
> > 'fields' => array('State.id', 'State.name', 'Country.name')
> > ));
>
> > However, it barks and complains that "Warning (512): SQL Error: 1054:
> > Unknown column 'Country.name' in 'field list'", which is because
> > 'Country' isn't included int he query ("Query: SELECT `State`.`id`,
> > `State`.`name`, `Country`.`name` FROM `states` AS `State` WHERE 1 =
> > 1 ORDER BY `State`.`name` ASC "), because (I'm assuming) "contain"
> > does not work.
>
> > If I do `find('all')` (with everything else being the same), it
> > returns without error ... albeit, completely screwed up for the select
> > list if I do 'State.country_id' for the "group" field (3rd in the
> > 'fields' array), it returns without error, albeit using the id and not
> > the name for the group.
>
> > Details added.
>
> > Confused or understood?
>
> > On Oct 6, 11:27 am, AD7six <[EMAIL PROTECTED]> wrote:
>
> > > On Oct 6, 8:20 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > > > Apparently doing `find('list')` doesn't like to take into account the
> > > > "contain" option.
> > > > Is this on purpose?
>
> > > > Scenario:
> > > > Have a list of States that needs to be grouped by Country name, 2
> > > > separate tables where State has the country_id.
>
> > > > Bug or intentional?
>
> > > Details missing
>
> > > deliberate or mistake?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: find('list') + "contain" option.
uh ... k ...
So for models there's the "find" function, whose first parameter can
be an assortment of strings depending on what you want to find ...
well, one of the ones I'm using is "list", which will generate a list
that's for easier usage in a select list.
Then there's also the possibility of an array of options as the second
parameter. One of these possible options is the "contain" key, which,
when used, would denote what associations to use while doing the find.
This option doesn't seem to take affect when I use it in conjunction
with `find('list')`.
Another thing you an do with the second 'options' array parameter is
declare how you want the list returned, and what it is to be grouped
by, for the select list.
In my case, I have a list of States ... I want them grouped by Country
name Therefore, I'm calling it like this:
$states = $this->User->State->find('list',
array('contain'
=> array('Country'),
'fields' => array('State.id', 'State.name', 'Country.name')
));
However, it barks and complains that "Warning (512): SQL Error: 1054:
Unknown column 'Country.name' in 'field list'", which is because
'Country' isn't included int he query ("Query: SELECT `State`.`id`,
`State`.`name`, `Country`.`name` FROM `states` AS `State` WHERE 1 =
1 ORDER BY `State`.`name` ASC "), because (I'm assuming) "contain"
does not work.
If I do `find('all')` (with everything else being the same), it
returns without error ... albeit, completely screwed up for the select
list if I do 'State.country_id' for the "group" field (3rd in the
'fields' array), it returns without error, albeit using the id and not
the name for the group.
Details added.
Confused or understood?
On Oct 6, 11:27 am, AD7six <[EMAIL PROTECTED]> wrote:
> On Oct 6, 8:20 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > Apparently doing `find('list')` doesn't like to take into account the
> > "contain" option.
> > Is this on purpose?
>
> > Scenario:
> > Have a list of States that needs to be grouped by Country name, 2
> > separate tables where State has the country_id.
>
> > Bug or intentional?
>
> Details missing
>
> deliberate or mistake?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
find('list') + "contain" option.
Apparently doing `find('list')` doesn't like to take into account the
"contain" option.
Is this on purpose?
Scenario:
Have a list of States that needs to be grouped by Country name, 2
separate tables where State has the country_id.
Bug or intentional?
Cheers
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Another HABTM issue : row with same Id getting over-written
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',
> > > > >
> > > > > 'associatio
Another HABTM issue : row with same Id getting over-written
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
HABTM webpage_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',
'foreignKey' =>
'webpage_type_id',
'conditions' =>
'',
'fields' => '',
'order' => ''
)
);
Seriously confused
I've searched the group, and came up empty handed - probably due to
diff keywords.
Cheers.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Another HABTM issue : row with same Id getting over-written
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
> > HABTM webpage_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',
> >
> > 'foreignKey' => 'webpage_type_id',
> >
> > 'conditions' => '',
> > 'fields' =>
> > '',
> > 'order' =>
> > ''
> > )
> > );
>
> > Seriously confused
>
> > I've searched the group, and came up empty handed - probably due to
> > diff keywords.
>
> > Cheers.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Models: Why not more Object Oriented??
Sorry, not meaning to be annoying, just grasping for understanding. Thanks to all :) On Sep 23, 5:42 pm, Nate <[EMAIL PROTECTED]> wrote: > Yah. We know. We'll get to it. > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Models: Why not more Object Oriented??
This is all well and good, in this specific example ... but the
underlying principle still exists: better OOP layout.
On Sep 23, 5:32 pm, "Jon Bennett" <[EMAIL PROTECTED]> wrote:
> > Even if `afterFind()` is used, I'd still be doing 1 more loop than I
> > should need to.
> > But thanks for the tip, it's all very useful.
>
> If you have logic that you need in the view, create a helper and add
> methods to it, like:
>
> // /app/helpers/ecom.php
> class EcomHelper extends Helper {
>
> public function calculate_totals($record)
> {
> # do stuff
> }
>
> }
>
> // A view of some sort
> foreach($data as $row):
> echo $Ecom->calculate_totals($row['Model']);
> endforeach;
>
> Though personally I would do this in the afterFind.
>
> jb
>
> --
>
> jon bennett
> w:http://www.jben.net/
> iChat (AIM): jbendotnet Skype: jon-bennett
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Models: Why not more Object Oriented??
Even if `afterFind()` is used, I'd still be doing 1 more loop than I should need to. But thanks for the tip, it's all very useful. On Sep 23, 4:55 pm, teknoid <[EMAIL PROTECTED]> wrote: > To address your specific example, such functionality should be handled > in models' afterFind(), where you can modify the returned data. > Also, take a look at the Set class in cake's API for some powerful > array manipulation tools. > > And as far as the array structure, it also depends on how deep your > binding is... once you get familiar with the way returned arrays are > structured, it really doesn't matter one way or another. > > On Sep 23, 6:07 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > Heh, I figured there was some intricacies that I'd forgotten about ... > > it's been a long time since I touched PHP4. > > > On Sep 23, 4:02 pm, John David Anderson <[EMAIL PROTECTED]> > > wrote: > > > > On Sep 23, 2008, at 3:52 PM, Brenton B wrote: > > > > > Hmmm ... never thought of backwards compatibility to PHP4 as a reason. > > > > I figured since PHP5 has been out for over 4 years (first beta was > > > > over 5 yrs ago) worrying about PHP4's support would've waned ... like, > > > > completely dropped off. > > > > So I'm guessing there must be some super fanciness in the Cake libs > > > > because PHP4 does support Classes and Objects, and I'm pretty sure > > > > PHP4 would still support the use cases previously described. > > > > How sure? ;) > > > > For one, see what happens when you try get_class() on an object of > > > type ClassNamesComeBackLowerCase in PHP4.x and you'll see (part) of > > > the problem. You can see how caseless classnames might screw up things > > > in a CakePHP setup. > > > > > Don't get me wrong, I'm still liking Cake, was just something I was > > > > thinking of while coding today. > > > > I promise you're not the first to bring it up. > > > > -- John --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Models: Why not more Object Oriented??
Heh, I figured there was some intricacies that I'd forgotten about ... it's been a long time since I touched PHP4. On Sep 23, 4:02 pm, John David Anderson <[EMAIL PROTECTED]> wrote: > On Sep 23, 2008, at 3:52 PM, Brenton B wrote: > > > > > Hmmm ... never thought of backwards compatibility to PHP4 as a reason. > > I figured since PHP5 has been out for over 4 years (first beta was > > over 5 yrs ago) worrying about PHP4's support would've waned ... like, > > completely dropped off. > > So I'm guessing there must be some super fanciness in the Cake libs > > because PHP4 does support Classes and Objects, and I'm pretty sure > > PHP4 would still support the use cases previously described. > > How sure? ;) > > For one, see what happens when you try get_class() on an object of > type ClassNamesComeBackLowerCase in PHP4.x and you'll see (part) of > the problem. You can see how caseless classnames might screw up things > in a CakePHP setup. > > > Don't get me wrong, I'm still liking Cake, was just something I was > > thinking of while coding today. > > I promise you're not the first to bring it up. > > -- John --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Models: Why not more Object Oriented??
Hmmm ... never thought of backwards compatibility to PHP4 as a reason. I figured since PHP5 has been out for over 4 years (first beta was over 5 yrs ago) worrying about PHP4's support would've waned ... like, completely dropped off. So I'm guessing there must be some super fanciness in the Cake libs because PHP4 does support Classes and Objects, and I'm pretty sure PHP4 would still support the use cases previously described. Don't get me wrong, I'm still liking Cake, was just something I was thinking of while coding today. On Sep 23, 3:40 pm, John David Anderson <[EMAIL PROTECTED]> wrote: > On Sep 23, 2008, at 3:34 PM, Brenton B wrote: > > > If anyone is still reading by this point (sorry it's so long), > > hopefully you can shed some light. > > PHP4 support. It's gotten us where we're at, and future versions of > Cake will be PHP5-based and more OOP-friendly. > > -- John --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Models: Why not more Object Oriented??
This one is a bit more for the dev team ... but since I doubt they
read this much, wonder if anyone else wants to chime in ...
One thing I'm struggling with is the lack of OOP on the part of the
models after a find, especially for a list.
Now, before I get flamed, let me explain what I mean.
If I do a `find('all')` I simply get a (possibly) multi-level
associative array. I don't have much of a problem with that, easy to
do typical PHP array function calls on that, but then I want to start
looping through and pulling records off of it and possibly doing some
extra stuff ...
Let's say I have an list of `PurchasedItems` for an Order form, each
PurchasedItem needs to have the taxes calculated. From what I've seen/
read, most do this in the View .. which might be all and good, but
doesn't seem very DRY or modular ... from an OOP standpoint, it would
make more sense to have a function called `calculate_subtotal()`
accessible from the View to do this. However, I have yet to find out a
way to do this, anything I've tried throws back an error ("Call to a
member function calculate_subtotal() on a non-object") .. obviously,
since it's an array, not an object. From what I've read, some are
suggesting looping in the Controller to calculate this ... so I'm
doing 2 loops? One in the Controller to calculate, and the other in
the View to display ... that doesn't make much sense.
Another head-scratcher is that in a `find('all')`, then subsequent
foreach loop, for associations, they're returned on the same level as
the object. Again, I'll explain ...
I've got a list of Webpages, each has a WebpageType. I do a
`find('all')` on the Webpages, I get something returned like:
Array
(
[0] => Array
(
[Webpage] => Array
(
[id] => 1
[user_id] => 1
[webpage_type_id] => 2
[url] => somewebsite.com
)
[WebpageType] => Array
(
[id] => 2
[name] => Blog
)
)
)
Now in my mind, WebpageType should not be on the same level as Webpage
because it is a 'technically' member of Webpage (since it
"belongsTo") ... I would think the result would be more like:
Array
(
[0] => Array
(
[Webpage] => Array
(
[id] => 1
[user_id] => 1
[webpage_type_id] => 2
[url] => somewebsite.com
[WebpageType] => Array
(
[id] => 2
[name] => Blog
)
)
)
)
Taking this principle with the first one (where it's all OOP), from
the View I could then access this in a foreach with:
$webpage->WebpageType->name;
If anyone is still reading by this point (sorry it's so long),
hopefully you can shed some light.
Thanks.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Containable: all + couple extras.
That's not a bad idea.
Would just really like to see something that adds onto it ... I'll
probably just code something up.
Thanks anyway.
On Sep 23, 1:25 pm, teknoid <[EMAIL PROTECTED]> wrote:
> I could be mistaken, but I've not seen a 'catch all' argument for
> Containable.
>
> If you find that you always do the same 'contain' for User... i.e.
> 'contain'=>array('Profile', 'Address', 'Images',
> 'Webpages'=>array('WebpageType'));
> you could make the above array as a var $defaultContain in the User
> model (or controller), then:
>
> $this->User->find('all', array('contain'=>$this->User-
>
> >defaultContain));
>
> On Sep 23, 2:45 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > So I've got a User a User has a Profile, Addresses, Images,
> > Webpages.
>
> > When I do a simple `find()`, by default it'll get the first level.
> > However, Webpages also has WebpageType.
>
> > So my options are to either bump up the recursivity by 1, which will
> > get the Addresses, but because of the increase recursiveness, it'll
> > get the User again.
>
> > Or use Containable; except by it's nature, I have to specify each of
> > Profile, Addresses, Images, Webpages.WebpageType ... so if I add
> > something to it, I'll have to go through and add it to each call as
> > well ... Bindable had a 'catch-all' with '*', which doesn't work with
> > Containable, and no documentation to the mention of it.
>
> > So I guess my question, has anyone thought up a sweet work around??
>
> > I'm really digging Cake, just taking me some time to get used to it.
>
> > Cheers
>
> > On Sep 23, 12:28 pm, teknoid <[EMAIL PROTECTED]> wrote:
>
> > > You should be more specific as to what you are tying to do...
>
> > > "get couple of things" doesn't really explain the issue.
>
> > > On Sep 23, 2:12 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > > > This isn't possible? Or just so obvious?
>
> > > > On Sep 22, 8:31 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > > > > I'm using the "Containable" behavior ...
> > > > > I want to get a couple extra specific things off one of the
> > > > > associations, but still want to get all the others.
> > > > > Instead of having to relist everything, is there anyway I can use '*'
> > > > > like the Bindable behavior had?? (since it's not deprecated)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Containable: all + couple extras.
So I've got a User a User has a Profile, Addresses, Images, Webpages. When I do a simple `find()`, by default it'll get the first level. However, Webpages also has WebpageType. So my options are to either bump up the recursivity by 1, which will get the Addresses, but because of the increase recursiveness, it'll get the User again. Or use Containable; except by it's nature, I have to specify each of Profile, Addresses, Images, Webpages.WebpageType ... so if I add something to it, I'll have to go through and add it to each call as well ... Bindable had a 'catch-all' with '*', which doesn't work with Containable, and no documentation to the mention of it. So I guess my question, has anyone thought up a sweet work around?? I'm really digging Cake, just taking me some time to get used to it. Cheers On Sep 23, 12:28 pm, teknoid <[EMAIL PROTECTED]> wrote: > You should be more specific as to what you are tying to do... > > "get couple of things" doesn't really explain the issue. > > On Sep 23, 2:12 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > This isn't possible? Or just so obvious? > > > On Sep 22, 8:31 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > > I'm using the "Containable" behavior ... > > > I want to get a couple extra specific things off one of the > > > associations, but still want to get all the others. > > > Instead of having to relist everything, is there anyway I can use '*' > > > like the Bindable behavior had?? (since it's not deprecated) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Containable: all + couple extras.
This isn't possible? Or just so obvious? On Sep 22, 8:31 pm, Brenton B <[EMAIL PROTECTED]> wrote: > I'm using the "Containable" behavior ... > I want to get a couple extra specific things off one of the > associations, but still want to get all the others. > Instead of having to relist everything, is there anyway I can use '*' > like the Bindable behavior had?? (since it's not deprecated) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Containable: all + couple extras.
I'm using the "Containable" behavior ... I want to get a couple extra specific things off one of the associations, but still want to get all the others. Instead of having to relist everything, is there anyway I can use '*' like the Bindable behavior had?? (since it's not deprecated) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: HABTM + 'with' only returning first unique.
Naturally not too long after I post I come across the Core
Behavior "Containable" (http://book.cakephp.org/view/474/Containable).
Same thing ... different name hopefully.
On Sep 22, 7:15 pm, Brenton B <[EMAIL PROTECTED]> wrote:
> I'm guessing this might be what's
> needed:http://bakery.cakephp.org/articles/view/bindable-behavior-control-you...
>
> Will check it out ...
>
> On Sep 22, 6:58 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > Still trying to wrap my head around Cake's intricacies ... and get RoR
> > conventions out of my head ...
>
> > So I've got a User
> > I've also got WebpageType (ex: Main, Bio, Blog, etc.)
> > I then have these 2 tables linked, which has an extra field for the
> > URL.
>
> > I've set this all up using HABTM and `with`.
>
> > All well and good, except if I have multiple of the same type of
> > webpage, in which case it only returns the first row of each unique
> > type. doh!!
>
> > Personally I think the HABTM + `with` doesn't really make much sense -
> > it's a bit reverse because it's getting the WebpageType with the join
> > attached. For example, in this specific circumstance I want a user and
> > all of the users webpages with the name of the type attached.
>
> > Now, of course, I could do increase how recursive it is, but it
> > obviously gets a few more levels than I want (because there are some
> > other tables that are joined that would end up retrieving the user
> > again). Or I could do some fancy juggling and bind some models
> > together dynamically, but that's adding some complexity on top of what
> > I figure should be fairly straight forward.
>
> > Keep in mind that I'm coming from a RoR background, where there is
> > something similar to the `with` fanciness; however, it's in the
> > retrieving. So when retrieving a record, you can specify which
> > associations to retrieve - most importantly, this is done as a
> > parameter in options:
>
> > user->find('first', array('with' => array('UserWebpageType' =>
> > array('WebpageType';
>
> > Something I'm missing?
>
> > Thanks.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: HABTM + 'with' only returning first unique.
I'm guessing this might be what's needed:
http://bakery.cakephp.org/articles/view/bindable-behavior-control-your-model-bindings
Will check it out ...
On Sep 22, 6:58 pm, Brenton B <[EMAIL PROTECTED]> wrote:
> Still trying to wrap my head around Cake's intricacies ... and get RoR
> conventions out of my head ...
>
> So I've got a User
> I've also got WebpageType (ex: Main, Bio, Blog, etc.)
> I then have these 2 tables linked, which has an extra field for the
> URL.
>
> I've set this all up using HABTM and `with`.
>
> All well and good, except if I have multiple of the same type of
> webpage, in which case it only returns the first row of each unique
> type. doh!!
>
> Personally I think the HABTM + `with` doesn't really make much sense -
> it's a bit reverse because it's getting the WebpageType with the join
> attached. For example, in this specific circumstance I want a user and
> all of the users webpages with the name of the type attached.
>
> Now, of course, I could do increase how recursive it is, but it
> obviously gets a few more levels than I want (because there are some
> other tables that are joined that would end up retrieving the user
> again). Or I could do some fancy juggling and bind some models
> together dynamically, but that's adding some complexity on top of what
> I figure should be fairly straight forward.
>
> Keep in mind that I'm coming from a RoR background, where there is
> something similar to the `with` fanciness; however, it's in the
> retrieving. So when retrieving a record, you can specify which
> associations to retrieve - most importantly, this is done as a
> parameter in options:
>
> user->find('first', array('with' => array('UserWebpageType' =>
> array('WebpageType';
>
> Something I'm missing?
>
> Thanks.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
HABTM + 'with' only returning first unique.
Still trying to wrap my head around Cake's intricacies ... and get RoR
conventions out of my head ...
So I've got a User
I've also got WebpageType (ex: Main, Bio, Blog, etc.)
I then have these 2 tables linked, which has an extra field for the
URL.
I've set this all up using HABTM and `with`.
All well and good, except if I have multiple of the same type of
webpage, in which case it only returns the first row of each unique
type. doh!!
Personally I think the HABTM + `with` doesn't really make much sense -
it's a bit reverse because it's getting the WebpageType with the join
attached. For example, in this specific circumstance I want a user and
all of the users webpages with the name of the type attached.
Now, of course, I could do increase how recursive it is, but it
obviously gets a few more levels than I want (because there are some
other tables that are joined that would end up retrieving the user
again). Or I could do some fancy juggling and bind some models
together dynamically, but that's adding some complexity on top of what
I figure should be fairly straight forward.
Keep in mind that I'm coming from a RoR background, where there is
something similar to the `with` fanciness; however, it's in the
retrieving. So when retrieving a record, you can specify which
associations to retrieve - most importantly, this is done as a
parameter in options:
user->find('first', array('with' => array('UserWebpageType' =>
array('WebpageType';
Something I'm missing?
Thanks.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: View-specific element (aka: why use an element?)
Cheers, that helps a lot!!
On Sep 22, 5:01 pm, Joel Perras <[EMAIL PROTECTED]> wrote:
> No problem. The more Rails converts, the better :-P
>
> The equivalent of App_controller.php and app_model.php in terms of
> views is slightly different than what you'd expect; in actuality, the
> implementation of view sub-classing allows you to define multiple
> custom View classes and attach different ones to different
> controllers.
>
> Example:
> You can create a custom view class such as app/views/app.php :
>
> class AppView extends View {
>
> // Define your View::partial() function here, using
> View::render() as a fallback.
>
> }
>
> To tell your application that you want to use this view class instead
> of the default one, define it in your app_controller.php :
>
> class AppController extends Controller {
> var $view = 'App';
>
> // Other AppController things..
>
> }
>
> Now you can use $this->partial() in your layouts & elements.
>
> As you can see, I've told my application to automagically load the
> 'App' view class that I've created. However, there's nothing stopping
> me from creating yet another view class and attaching it to a specific
> controller instead of the app_controller. The caveat here is that you
> need to be aware of what goes in a View and what should go in a
> Helper, but that's basic MVC design. In your case though, I believe a
> custom view to be the right implementation.
>
> Check out this article (esp. the comments) for an interesting use of
> View
> subclassing:http://cakebaker.42dh.com/2008/08/22/an-idea-for-loading-helpers-in-t...
>
> hth,
> -J.
>
> On Sep 22, 6:22 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > Yeah, I've prefixed the element with an underscore.
> > Hmmm ... excellent (and obvious) idea with just using the relative
> > path from `elements` ...
> > Makes me think it'd be nice to write a `partial ()` function which
> > would take in the name and prepend the path + current controller; but
> > I can't seem to find out how to override the View similar to
> > app_controller for Controller, any thoughts??
>
> > I took a look at the Mini-controller but it's not quite fitting my
> > purposes and seems like extra work for something that should be
> > trivial (not to mention reading the page was hurting my eyes).
>
> > Thanks Joel!!
>
> > On Sep 22, 3:32 pm, Joel Perras <[EMAIL PROTECTED]> wrote:
>
> > > I usually put these Controller-specific elements inside the same
> > > folder as the controller they are associated to.
> > > Example: create an 'emphasis.ctp' file, and place it in your views/
> > > photographers/ folder. You can then render this element inside a
> > > photographer view template by calling element('../
> > > photographers/emphasis'); ?>. Remember that to pass in data to your
> > > element you need to pass in a data array as your second argument to
> > > $this::element (data given to the view is not automatically available
> > > to the element).
>
> > > You can, of course, place an underscore infront of the element name to
> > > adhere to a standard convention; since these elements are never
> > > directly associated to a controller action, then there shouldn't be a
> > > problem.
> > > This ensures that your application separates the global elements (e.g.
> > > header, footer) from the controller/view-specific elements.
>
> > > Alternatively, you could use a technique pioneered by AD7six known as
> > > mini-controllers:http://www.ad7six.com/MiBlog/Blogs/view/MiniControllers
> > > While I have not used it, there is a not-so-small legion of Bakers who
> > > swear it's the best thing since sliced bread.
>
> > > hth,
>
> > > -J.
>
> > > On Sep 22, 3:17 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > > > Here's the scenario:
>
> > > > I've got a list of Photographers; each Photographer has a list of
> > > > Emphases that they specialize in; each Emphasis has additional info
> > > > (like 'experience').
> > > > In the Edit view, I'm looping through the Emphases and creating the
> > > > form. However, I also have an "Add new" ajax functionality to
> > > > dynamically add a new Emphasis.
>
> > > > Now, obviously these 2 forms are identical, and would much rather
> > > > modularize these in to a single piece.
>
> > > &
Re: View-specific element (aka: why use an element?)
Yeah, I've prefixed the element with an underscore.
Hmmm ... excellent (and obvious) idea with just using the relative
path from `elements` ...
Makes me think it'd be nice to write a `partial ()` function which
would take in the name and prepend the path + current controller; but
I can't seem to find out how to override the View similar to
app_controller for Controller, any thoughts??
I took a look at the Mini-controller but it's not quite fitting my
purposes and seems like extra work for something that should be
trivial (not to mention reading the page was hurting my eyes).
Thanks Joel!!
On Sep 22, 3:32 pm, Joel Perras <[EMAIL PROTECTED]> wrote:
> I usually put these Controller-specific elements inside the same
> folder as the controller they are associated to.
> Example: create an 'emphasis.ctp' file, and place it in your views/
> photographers/ folder. You can then render this element inside a
> photographer view template by calling element('../
> photographers/emphasis'); ?>. Remember that to pass in data to your
> element you need to pass in a data array as your second argument to
> $this::element (data given to the view is not automatically available
> to the element).
>
> You can, of course, place an underscore infront of the element name to
> adhere to a standard convention; since these elements are never
> directly associated to a controller action, then there shouldn't be a
> problem.
> This ensures that your application separates the global elements (e.g.
> header, footer) from the controller/view-specific elements.
>
> Alternatively, you could use a technique pioneered by AD7six known as
> mini-controllers:http://www.ad7six.com/MiBlog/Blogs/view/MiniControllers
> While I have not used it, there is a not-so-small legion of Bakers who
> swear it's the best thing since sliced bread.
>
> hth,
>
> -J.
>
> On Sep 22, 3:17 pm, Brenton B <[EMAIL PROTECTED]> wrote:
>
> > Here's the scenario:
>
> > I've got a list of Photographers; each Photographer has a list of
> > Emphases that they specialize in; each Emphasis has additional info
> > (like 'experience').
> > In the Edit view, I'm looping through the Emphases and creating the
> > form. However, I also have an "Add new" ajax functionality to
> > dynamically add a new Emphasis.
>
> > Now, obviously these 2 forms are identical, and would much rather
> > modularize these in to a single piece.
>
> > So far, from what I've found, my options are:
>
> > 1.) requestAction - which would retrieve the list of Emphases.
> > However: I already have that list when I retrieved the Photographer's
> > info, so that seems kind of redundant (plus processing overhead - yes,
> > I know it wouldn't be a lot)
>
> > 2.) renderElement. And here's my beef with 'elements': I will only
> > ever need this 'Emphasis' requirement from within 'Photographer', so
> > why should it go in 'elements' which are intended to be "small blocks
> > of presentation code that needs to be repeated from page to page...".
> > Strictly speaking, this is a small block that is repeated; however,
> > it's only specific to a Photographer. It just doesn't make much sense
> > to have it in a "global"-type folder.
>
> > I'm coming from a RoR background where such things would simply be
> > prefixed with an underscore ... so in this case, rather than have
> > `elements/emphasis.ctp` it would be in `photographers/
> > _emphasis.ctp` ... it's just more modular...
>
> > Thoughts??
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
View-specific element (aka: why use an element?)
Here's the scenario: I've got a list of Photographers; each Photographer has a list of Emphases that they specialize in; each Emphasis has additional info (like 'experience'). In the Edit view, I'm looping through the Emphases and creating the form. However, I also have an "Add new" ajax functionality to dynamically add a new Emphasis. Now, obviously these 2 forms are identical, and would much rather modularize these in to a single piece. So far, from what I've found, my options are: 1.) requestAction - which would retrieve the list of Emphases. However: I already have that list when I retrieved the Photographer's info, so that seems kind of redundant (plus processing overhead - yes, I know it wouldn't be a lot) 2.) renderElement. And here's my beef with 'elements': I will only ever need this 'Emphasis' requirement from within 'Photographer', so why should it go in 'elements' which are intended to be "small blocks of presentation code that needs to be repeated from page to page...". Strictly speaking, this is a small block that is repeated; however, it's only specific to a Photographer. It just doesn't make much sense to have it in a "global"-type folder. I'm coming from a RoR background where such things would simply be prefixed with an underscore ... so in this case, rather than have `elements/emphasis.ctp` it would be in `photographers/ _emphasis.ctp` ... it's just more modular... Thoughts?? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Plural name: Emphases <-> Emphasis
*face palm* doh!!! Well that's embarrassing ... long day :( Thanks!! On Sep 20, 9:08 pm, Joel Perras <[EMAIL PROTECTED]> wrote: > FTCB (From the CookBook): "[...] join table’s name needs to include > the names of both models involved, in alphabetical order". > > So it should be emphases_photographers. > > http://book.cakephp.org/view/83/hasAndBelongsToMany-HABTM > > -J. > > On Sep 20, 9:10 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > Hmmm ... I sort of have this working ... however, now that I have a > > join table for HABTM it's fubarred again. > > The table is photographers_emphases, so class is > > PhotographersEmphasis ... does the inflector take into account join > > tables like that properly? > > > On Sep 17, 11:06 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > > Ha! harsh > > > > Thanks Joel, I figured it had to be straight forward (feel kinda silly > > > now, meh), was just going in circles looking for it. > > > > On Sep 17, 8:03 pm, "David C. Zentgraf" <[EMAIL PROTECTED]> wrote: > > > > > OT: > > > > Inflector recently thought the singular form of Pasta is Pastum. > > > > That class can be really good for a laugh sometimes. :-D > > > > > On 18 Sep 2008, at 09:54, Joel Perras wrote: > > > > > > If Cake doesn't inflect the word 'emphasis' properly, you can add a > > > > > custom inflection: > > > > > >http://book.cakephp.org/view/47/Custom-Inflections > > > > > > -J. > > > > > > On Sep 17, 8:27 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > > >> Model is 'emphasis', plural is 'emphases'. > > > > >> Yet Cake doesn't seem to like it. > > > > >> libs/controller/inflector.php ... line 89 seems to have what it > > > > >> takes, > > > > >> but no love ... > > > > > >> Thoughts? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Plural name: Emphases <-> Emphasis
Hmmm ... I sort of have this working ... however, now that I have a join table for HABTM it's fubarred again. The table is photographers_emphases, so class is PhotographersEmphasis ... does the inflector take into account join tables like that properly? On Sep 17, 11:06 pm, Brenton B <[EMAIL PROTECTED]> wrote: > Ha! harsh > > Thanks Joel, I figured it had to be straight forward (feel kinda silly > now, meh), was just going in circles looking for it. > > On Sep 17, 8:03 pm, "David C. Zentgraf" <[EMAIL PROTECTED]> wrote: > > > OT: > > Inflector recently thought the singular form of Pasta is Pastum. > > That class can be really good for a laugh sometimes. :-D > > > On 18 Sep 2008, at 09:54, Joel Perras wrote: > > > > If Cake doesn't inflect the word 'emphasis' properly, you can add a > > > custom inflection: > > > >http://book.cakephp.org/view/47/Custom-Inflections > > > > -J. > > > > On Sep 17, 8:27 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > >> Model is 'emphasis', plural is 'emphases'. > > >> Yet Cake doesn't seem to like it. > > >> libs/controller/inflector.php ... line 89 seems to have what it > > >> takes, > > >> but no love ... > > > >> Thoughts? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Sorting without Paginator
Thanks for the reply. That's all well and good if I'm going from a certain offset, but if I want the whole shebang I wouldn't even need an offset or a limit. I'm speaking more specifically to the 'limit' option in the Pagination helper. Although, I suppose I could try Custom Query Pagination. On Sep 17, 7:04 pm, Joel Perras <[EMAIL PROTECTED]> wrote: > FYI, the MySQL docs actually recommend that to "retrieve all rows from > a certain offset up to the end of the result set, you can use some > large number for the second parameter". You can always wrap this up > in a custom pagination function, which should achieve your desired > result. If you want to get fancy, you could figure out an efficient > method for obtaining the total number of records (through count > caching, I suppose), and then use that as your upper limit. > > MySQL quote cited above:http://dev.mysql.com/doc/refman/5.0/en/select.html > > -Joel. > > On Sep 17, 6:15 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > Hello. > > I would like to make use of the sort functionality in the Paginator > > class; however, don't want to actually paginate. > > My options are to either strip out the Sort stuff and create a new > > helper, or set the 'limit' in the options to something crazy high - > > which I think is a bit of a hack. > > I was hoping that the 'limit' option would take a value like 'all' and > > just return all (obviously), but no such luck. > > Anyone else have any other ideas? > > Naturally, I could go with just passing args in the `find` function, > > but just thought I'd check. > > > Cheers --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Plural name: Emphases <-> Emphasis
Ha! harsh Thanks Joel, I figured it had to be straight forward (feel kinda silly now, meh), was just going in circles looking for it. On Sep 17, 8:03 pm, "David C. Zentgraf" <[EMAIL PROTECTED]> wrote: > OT: > Inflector recently thought the singular form of Pasta is Pastum. > That class can be really good for a laugh sometimes. :-D > > On 18 Sep 2008, at 09:54, Joel Perras wrote: > > > > > If Cake doesn't inflect the word 'emphasis' properly, you can add a > > custom inflection: > > >http://book.cakephp.org/view/47/Custom-Inflections > > > -J. > > > On Sep 17, 8:27 pm, Brenton B <[EMAIL PROTECTED]> wrote: > >> Model is 'emphasis', plural is 'emphases'. > >> Yet Cake doesn't seem to like it. > >> libs/controller/inflector.php ... line 89 seems to have what it > >> takes, > >> but no love ... > > >> Thoughts? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Plural name: Emphases <-> Emphasis
Model is 'emphasis', plural is 'emphases'. Yet Cake doesn't seem to like it. libs/controller/inflector.php ... line 89 seems to have what it takes, but no love ... Thoughts? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Sorting without Paginator
Hello. I would like to make use of the sort functionality in the Paginator class; however, don't want to actually paginate. My options are to either strip out the Sort stuff and create a new helper, or set the 'limit' in the options to something crazy high - which I think is a bit of a hack. I was hoping that the 'limit' option would take a value like 'all' and just return all (obviously), but no such luck. Anyone else have any other ideas? Naturally, I could go with just passing args in the `find` function, but just thought I'd check. Cheers --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Unsigned Integers??
Yeah, makes sense. On Sep 16, 5:00 pm, villas <[EMAIL PROTECTED]> wrote: > Hi, > I think only the dev team can explain exactly why Cake is the way it > is. However, I thought that you'd probably answered your own > question :-) > > Many of us do not use MySql and we are delighted that so much effort > is being made to develop Cake in a DB-agnostic way. The idea is that > Cake developers can change the DB back-end just by changing a config > file. It is a wonderful concept and we wouldn't want to spoil it by > introducingunsignedinteger field-types if that reduces the > portability of our code without any good reason. > > On Sep 16, 10:59 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > Really, no one knows? For serious? > > > On Sep 13, 9:47 pm, Brenton B <[EMAIL PROTECTED]> wrote: > > > > So, in MySQL I can create a table with a field that has type integer > > > withunsignedinteger, which as we all know will define the length to > > > 10 and doubles the maximum possible value. > > > So why doesn't the `schema` console function take this into account? > > > For my specs, the chances of having more than 2,147,483,647 records is > > > pretty negligible, but still ... > > > > I'll chalk this up to storage-type dependency ... (ex: MySQL can do > > >unsignedints, but others can't) ... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Unsigned Integers??
Really, no one knows? For serious? On Sep 13, 9:47 pm, Brenton B <[EMAIL PROTECTED]> wrote: > So, in MySQL I can create a table with a field that has type integer > with unsigned integer, which as we all know will define the length to > 10 and doubles the maximum possible value. > So why doesn't the `schema` console function take this into account? > For my specs, the chances of having more than 2,147,483,647 records is > pretty negligible, but still ... > > I'll chalk this up to storage-type dependency ... (ex: MySQL can do > unsigned ints, but others can't) ... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
