We are in the middle of developing an application where we need to be able to add and remove attributes to a model when it is running. We have no problems removing the attribute with: ActiveRecord::Schema.define do remove_column [table_name], [new_colum_name] end but session that are already have loaded the object fails on update, because the attribute does not exits in the database. Any one have any good idea on how to update the object already in session with the new schema information? A side note: I know it is normal to move information like this out into its own table/model object, but because of performance issues we would like to keep all information in one table. IsBOF --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Do you have to stick the whole object in the session or could you just store its id instead? Fred -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> > > Any one have any good idea on how to update the object already in > session with the new schema information? > >Don''t know your exact scenario (have data you want to preserve in the object, etc...) but maybe class.reset_column_information with an object.reload ... or something like that? -- Andrew Stone --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Okay, don''t think I''m picking on you or anything but it''s *really* frustrating to see this sort of thing. Either your schema changes happen infrequently enough that a migrate/ deploy is a reasonable strategy *or* you are seriously abusing the relational model. I rarely feel issues have no middle-ground but in this instance... it''s one or the other. Now, maybe you''ve *really* done your homework and *proved* (in a way to ensure Zed Shaw wouldn''t tear you a new one) that the *only* way to get the performance you require is to batter your schema. But I suspect that''s not the case and you simply haven''t figured out the best way to solve your problem. I''m available for mentoring and code reviews and my rates are reasonable so feel free to contact me off-list. Of course, I''ve probably offended you so I''m not expecting an email - so find someone, *anyone* good, to review your code show you what you need to be doing in your particular case. Good Luck Trevor On 17-Nov-06, at 5:31 AM, IsBOF wrote:> > We are in the middle of developing an application where we need to be > able to add and remove attributes to a model when it is running. We > have no problems removing the attribute with: > > ActiveRecord::Schema.define do > remove_column [table_name], [new_colum_name] > end > > but session that are already have loaded the object fails on update, > because the attribute does not exits in the database. > > Any one have any good idea on how to update the object already in > session with the new schema information? > > A side note: I know it is normal to move information like this out > into > its own table/model object, but because of performance issues we would > like to keep all information in one table. > > IsBOF > > >--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
thanks for the suggestions. 1. We use only the id in the session, it looks like rails caches some information so it we get the "old" object schema with the field we have removed back. 2. reset_column_information - really resets the object information to the point where it is unable to find any attributes or has_many on the object. Trevor: We have tried with a "correct" relations model. This result in a unacceptable performance issues (some thing like 200 updates on a submit). And the remove/add of column happens frequently. Best regards, Rasmus On Nov 17, 7:36 pm, Trevor Squires <tre...-k8q5a0yEZAgS+FvcfC7Uqw@public.gmane.org> wrote:> Okay, > > don''t think I''m picking on you or anything but it''s *really* > frustrating to see this sort of thing. > > Either your schema changes happen infrequently enough that a migrate/ > deploy is a reasonable strategy *or* you are seriously abusing the > relational model. I rarely feel issues have no middle-ground but in > this instance... it''s one or the other. > > Now, maybe you''ve *really* done your homework and *proved* (in a way > to ensure Zed Shaw wouldn''t tear you a new one) that the *only* way > to get the performance you require is to batter your schema. But I > suspect that''s not the case and you simply haven''t figured out the > best way to solve your problem. > > I''m available for mentoring and code reviews and my rates are > reasonable so feel free to contact me off-list. > > Of course, I''ve probably offended you so I''m not expecting an email - > so find someone, *anyone* good, to review your code show you what you > need to be doing in your particular case. > > Good Luck > Trevor > > On 17-Nov-06, at 5:31 AM,IsBOFwrote: > > > > > We are in the middle of developing an application where we need to be > > able to add and remove attributes to a model when it is running. We > > have no problems removing the attribute with: > > > ActiveRecord::Schema.define do > > remove_column [table_name], [new_colum_name] > > end > > > but session that are already have loaded the object fails on update, > > because the attribute does not exits in the database. > > > Any one have any good idea on how to update the object already in > > session with the new schema information? > > > A side note: I know it is normal to move information like this out > > into > > its own table/model object, but because of performance issues we would > > like to keep all information in one table. > > >IsBOF--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
IsBOF wrote:> thanks for the suggestions. > > 1. We use only the id in the session, it looks like rails caches some > information so it we get the "old" object schema with the field we have > removed back. > > 2. reset_column_information - really resets the object information to > the point where it is unable to find any attributes or has_many on the > object. > > Trevor: We have tried with a "correct" relations model. This result in > a unacceptable performance issues (some thing like 200 updates on a > submit). And the remove/add of column happens frequently. > > Best regards, > > RasmusRails was really not designed to handle this. In production mode, it caches the classes, which include schema info for Models. You could turn off cache class caching for production but that would create a huge performance drop. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 11/19/06, Alex Wayne <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > IsBOF wrote: > > thanks for the suggestions. > > > > 1. We use only the id in the session, it looks like rails caches some > > information so it we get the "old" object schema with the field we have > > removed back. > > > > 2. reset_column_information - really resets the object information to > > the point where it is unable to find any attributes or has_many on the > > object. > > > > Trevor: We have tried with a "correct" relations model. This result in > > a unacceptable performance issues (some thing like 200 updates on a > > submit). And the remove/add of column happens frequently. > > > > Best regards, > > > > Rasmus > > Rails was really not designed to handle this. In production mode, it > caches the classes, which include schema info for Models. You could > turn off cache class caching for production but that would create a huge > performance drop. > > -- > Posted via http://www.ruby-forum.com/. > > > >Haha, yep, something doesn''t sound right... :) Rasmus - maybe if you described the use case scenario a bit, we might be able to figure out a better strategy than adding/removing columns at run time. I can''t imagine ever wanting to do this. -- Scott Becker Electro Interactive, Inc. Office: 813-333-5508 http://www.ElectroInteractive.com <http://www.electrointeractive.com/> --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---