Same thing though.... saving a category doesn't necessarily mean I need to save every post... so you have to choose the option that is less stressful... imagine a category with 10,000 posts.... updating the category would require you to save 10,000 posts...
same with any parent-child relationship... I haven't played with it in awhile, so I can comment specifically on your example with calling category.post_ids = post.id auto saving it, unless you're calling it during a create call... to me that would seem incorrect... That being said, post.category_ids is the way it would need to be done... because the posts are assigned the category... in this case calling that SHOULD NOT save the post, and should require me to save it manutally..... if I do post.create( params[:post] ) and one of the params is category_ids[ 1,4,6] then on the create the post is saved.... if I'm in the middle of am action and go post.category_ids = 1,2,3 then it SHOULD NOT save until I call post.save I think I just confused myself. On Oct 31, 3:24 pm, TomRossi7 <[EMAIL PROTECTED]> wrote: > Even in the case you mention, for adding a category to a post, I would > think you would use "past.category = category", or the > "post.category_id = category.id" method -- neither method would cause > the post to save until you called "post.save". > > However, if you were to call "category.post_ids = post.id", it would > immediately save the post -- now "post.save" is not required. Oh > wait! If the category was a NEW category it wouldn't save the post > and now you would need to call "post.save". > > The inconsistent behavior makes it hard for me to use this very cool > method. Not a lot of people chiming in so sw0rdfish, I'm thinking my > opinion matters even less! > > Thanks, > Tom > > On Oct 31, 3:00 pm, sw0rdfish <[EMAIL PROTECTED]> wrote: > > > I disagree... that should be up to the developer to check... like my > > example, why do I need to validate the category, each time I post? > > > My feeling is that if it's something that you need to have, then > > create a before_filter and have it validate, otherwise you're > > validating things that never change... > > > although I can see your argument for consistency... I still have no > > problem with the way it is now... > > > That being said, my opinion rarely matter :P > > > On Oct 30, 1:05 pm,TomRossi7<[EMAIL PROTECTED]> wrote: > > > > Why shouldn't it be changed right away? Because the parent may be > > > invalid. > > > > Really, the problem is consistency. If are doing an update to the > > > parent and children and the parent is invalid, the children may or may > > > not be affected. The consistent way to handle it would be to not > > > update the children until the parent is saved. IMHO > > > > Thanks, > > > Tom > > > > On Oct 30, 11:32 am, sw0rdfish <[EMAIL PROTECTED]> wrote: > > > > > I don't think it's odd at all.... the only reason it's not saved until > > > > the Parent is initially saved is if the parent has no ID, how cna you > > > > assign parent_id to the child ( or the join table ). > > > > > If you're modifying the children w/o touching the parent.... say > > > > categories and posts in those categories.... It would be up to the > > > > category model to validate any changes you make to it... and if you > > > > changed a post in one of those categories... or changed the category > > > > the post belonged to... why shouldn't it be changed right away? Why > > > > would I need to re-validate the category? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
