The explanation about the association add and remove methods has definitely cleared up the way I was thinking abt these methods. I get it now. Thanks!
I have a few more questions (around transactions/associations) but its a different topic. I will search the forums first before I shoot those out. Thanks again for taking time to explain the nuances of these APIs. -Ajay On Nov 18, 2:41 am, Jeremy Evans <[EMAIL PROTECTED]> wrote: > On Nov 17, 12:10 pm, Ajay CB <[EMAIL PROTECTED]> wrote: > > > Thanks for the reply! > > > > This is the correct way to handle it. To handle updates: > > > > o.add_item(x) unless o.items.include?(x) > > > Won't this skip the update if there is one? Ideally I need to find, > > modify and call save on the item. > > If the item is already in the association, there should be no need to > save it, unless you are modifying other values in the item. If you > are modifying other values, you should save those changes separately > (via x.save), as relying on the association code to do so is unwise > (it currently calls .save(), but I make no guarantee that later it > won't call save(foreign_key) to just update a single column). > > > > No. Associations are not proxies, so this won't work as you think. > > > Just use the add_ and remove_ methods. If you are unsure if the item > > > you are adding already exists in the association, you need to check it > > > manually. You can do this by overriding add_item and calling super > > > only if the item isn't already in the association, and you may want to > > > go that route if it makes your code simpler. > > > Can I actually override the add_item method? coz I thought it belonged > > to the Order (Model) class. > > I can try aliasing to something else and calling it though! The only > > pain is that I need to do this in more than one place. > > There's no need to alias in 2.7. You can override the add_item method > and call super. You could theoretically use this to not add the item > and instead just save it instead if the item is already in the > association but values other than the foreign key are different (not > that I recommend that approach). > > > Few more question: > > > Any reason only add_ and remove_ are there but not update_ ? > > Because all add_ and remove_ are designed to do is set up an > association between two objects. For a one_to_many, that involves > setting or unsetting the foreign key and saving the object passed. > For many_to_many, it involves adding or removing a record from the > join table. If you want to change an attribute of the associated > item, you should call .save on that associated item, you should not > expect magical behavior from add_ or remove_. > > > Is it possible to have add_or_upd_ which will be more useful ? > > > Atleast in mysql its possible to do this in one query using the > > 'insert...on duplicate key update' syntax (http://dev.mysql.com/doc/ > > refman/5.0/en/insert-on-duplicate.html) > > You can also use REPLACE if you are using MySQL. However, there's no > support in Sequel::Model for that. > > > Its not standard SQL - but can be easily mimicked by catching dup key > > and firing an update for DBs that dont have an equivalent.(It is not > > atomic but atleast will work in 99.99% of the cases) > > Working in 99.99% of cases is not good. One of the main reason to use > a database is for full ACID compliance. Obviously you don't care too > much about that if you are recommending that approach. It's a bad > idea anyway, as Sequel should not try to insert existing records, and > newly inserted records should not already exist in the database. > > The main issue here is you may be thinking add_ means SQL INSERT (and > maybe remove_ means SQL DELETE). That's not the case. You should > think of add_ as adding something to the association, not the object > to the database, and remove_ as removing the association, not the > object from the database. An easy way to reason about this is to > assume all objects already exist in the database. Then, for a > one_to_many association, add_ just updates the foreign key of the > object passed to be the primary key of the current object, and remove > updates the foreign key to nil. For many_to_many associations, this > is easier to understand, as add_ and remove_ only affect the join > table, they don't affect the table of either model. > > Jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sequel-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/sequel-talk?hl=en -~----------~----~----~----~------~----~------~--~---
