I have the rails antipatterns book and I am doing some refactoring. Is there a big resource difference between a rails model backed with a db table and just a regular model other than the metaprogramming methods being defined for the rails model/table -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Chris Habgood wrote in post #974022:> I have the rails antipatterns book and I am doing some refactoring. Is > there a big resource difference between a rails model backed with a db > table > and just a regular model other than the metaprogramming methods being > defined for the rails model/tableResource difference? You mean in terms of performance or something else? I''m not sure I get what you''re asking... Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Ya, memory usage, system performance and such. -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
anybody? -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 12 January 2011 17:59, Me <chabgood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> anybody?Perhaps you could explain in more detail what you mean. Give an example of the comparison you are trying to make. Colin -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
rails models: class me end class me < ActiveRecord::Base end Does the rails AR one use much more system resources than the ruby class? Other than the methods being defined for the AR one. -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 12 January 2011 18:15, Me <chabgood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> rails models: > class me > end > class me < ActiveRecord::Base > end > Does the rails AR one use much more system resources than the ruby class? > Other than the methods being defined for the AR one.Are you asking whether a class derived from ActiveRecord::Base uses more resources than one not so derived, apart from the resources used by ActiveRecord::Base? Sorry that seems to me to be not a useful question to ask. As I said previously if you could give some background as to why you are asking the question it may make more sense to me. Colin -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
OK from my first post. I am refactoring trying to make my app lean and agile. The less models loaded up the less memory obviously. I was curious if refactored out the DB portion and left the ruby model if it would have a noticeable impact or whether getting rid of the model and refactor into another on needed is a better way to lean the app. I am following the Rails anitpatterns book for this stuff. -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 12 January 2011 18:32, Me <chabgood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: Please quote the previous message and insert your comments at the appropriate points. It makes it easier to follow the thread. Thanks.> OK from my first post. I am refactoring trying to make my app lean and > agile. The less models loaded up the less memory obviously.Not necessarily. In terms of resources just loading models I would think it is more down to lines of code than number of models.> I was curious > if refactored out the DB portion and left the ruby model if it would have a > noticeable impactPerhaps I am being particularly dense today, again I do not understand what you mean by refactoring out the db portion and leaving the Ruby model.> or whether getting rid of the model and refactor into > another on needed is a better way to lean the app.Do you mean combining non-AR models or what? Colin -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
not sure what else to say. If you have a db table with 2 lines that are never going to change. You refactor that into the other model that references it and remove the original AR model. I was wondering, when you remove the table if you were to keep the original model but refactor the stuf into that mode instead of the referring model does it consume the same memory, BW, whatever, as opposed to the AR version of the model. -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Just to be clear, what specific performance tests are you having a problem with? Refactoring for better readability/maintainability every time your tests are green is a good practice. Trying to make micro-optimizations in memory profile, sql queries, caching, etc without a specific failing performance test and profiling results showing which query or page load is causing the problem just burns time and obfuscates your code. Apart from anything else, the things that make your app slow are probably not those that you expect it to be. The only thing I would say is that if you have a transient object that doesn''t require persistence (I have a location object in a new app - I don''t store locations - I just use them to handle geocoding and to return a list of places from a third party service) from what I understand (I''m still new to best Rails practices), it''s quite reasonable to put that in the lib directory. I wouldn''t wrap an entire AR lifecycle around a Class that I did not plan to persist the instances of. But that''s not to improve performance (although it might in some way) but because it seems more semantically accurate - it better expresses my intent. Best Wishes, Peter On Jan 12, 2011, at 4:14 PM, Me wrote:> not sure what else to say. If you have a db table with 2 lines that are never going to change. You refactor that into the other model that references it and remove the original AR model. I was wondering, when you remove the table if you were to keep the original model but refactor the stuf into that mode instead of the referring model does it consume the same memory, BW, whatever, as opposed to the AR version of the model. > > -- > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.-- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 12 January 2011 21:14, Me <chabgood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: To repeat, please quote the message you are replying to. Thanks> not sure what else to say. If you have a db table with 2 lines that are > never going to change. You refactor that into the other model that > references it and remove the original AR model. I was wondering, when you > remove the table if you were to keep the original model but refactor the > stuf into that mode instead of the referring model does it consume the same > memory, BW, whatever, as opposed to the AR version of the model.A key fact missing previously was that you have a very small table and could just hard code the data. The answer is who cares? Don''t worry about it unless you have performance or resource problems, in which case profile the code to find out where the problem lies and then address it. I can virtually guarantee that the bottlenecks or resource hogs will not be in the areas you might anticipate beforehand. Colin -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
I would think that a select box populated by an array or hash is MUCH faster and less system intensive than doing any db lookup. -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
It probably is, but why were you putting the data into a database? If there''s a valid reason to do that, do it and then fix db performance with caching if it becomes a limiting factor. If there''s not a valid reason to put the data into a database, why would you do so? Start with the simplest thing that would possibly work to get your tests passing and go from there. There was some discourse on one of the agile-like lists (maybe the XP list) recently with some people suggesting you shouldn''t actually add support for a db to an app until you have the first test that won''t pass simply by using in memory representations. That''s a little extreme for me, but certainly I wouldn''t put stuff into a db unless there was a good reason. And if there is a good reason for it being there, I wouldn''t remove it for performance reasons until I had failing performance tests and profiling that pointed to that query as being part of my problem. Google "premature optimization" Best Wishes, Peter On Jan 12, 2011, at 4:45 PM, Me wrote:> I would think that a select box populated by an array or hash is MUCH faster and less system intensive than doing any db lookup. > > -- > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.-- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Peter Bell wrote in post #974422:> It probably is, but why were you putting the data into a database? If > there''s a valid reason to do that, do it and then fix db performance > with caching if it becomes a limiting factor. > > If there''s not a valid reason to put the data into a database, why would > you do so? Start with the simplest thing that would possibly work to get > your tests passing and go from there.[...] With Rails, sometimes using a DB is the simplest thing, and it''s actually harder not to do so. But I agree with the sentiment. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Maybe so but you do not have to 3rd level normalize EVERY thing in a db. I learned to normalize your tables. BUT, now if you have only several items that are fixed that are not going to change it is beter to NOT put it in the db if you are not going to change it or need it to create an interface to manage it. -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Please quote when replying. Chris Habgood wrote in post #974782:> Maybe so but you do not have to 3rd level normalize EVERY thing in a db.Yes, you absolutely *do* have to normalize at least to 3NF. The only excuse for a denormalized schema is if you''ve actually *measured* that you''ve got a performance bottleneck that denormalization will solve (note: in 11 years of Web application development, I''ve never once had to do this).> I > learned to normalize your tables. BUT, now if you have only several > items > that are fixed that are not going to change it is beter to NOT put it in > the > db if you are not going to change it or need it to create an interface > to > manage it.Often true. But that''s a separate issue. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Jan 14, 2011, at 12:23 AM, Marnen Laibow-Koser wrote:> Please quote when replying. > > Chris Habgood wrote in post #974782: >> Maybe so but you do not have to 3rd level normalize EVERY thing in a db. > > Yes, you absolutely *do* have to normalize at least to 3NF. The only > excuse for a denormalized schema is if you''ve actually *measured* that > you''ve got a performance bottleneck that denormalization will solve > (note: in 11 years of Web application development, I''ve never once had > to do this).i think 11 years create u too old school... 3fn in web development? our dude, so if u like problems -)) if u use rails, ar- pattern, thinkin in models, not in database schema. + counter_caches columns (helpfull in development)> >> I >> learned to normalize your tables. BUT, now if you have only several >> items >> that are fixed that are not going to change it is beter to NOT put it in >> the >> db if you are not going to change it or need it to create an interface >> to >> manage it. > > Often true. But that''s a separate issue. > > Best, > -- > Marnen Laibow-Koser > http://www.marnen.org > marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org > > -- > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en. >-- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Ivan Nastyukhin wrote in post #974793:> On Jan 14, 2011, at 12:23 AM, Marnen Laibow-Koser wrote: > >> Please quote when replying. >> >> Chris Habgood wrote in post #974782: >>> Maybe so but you do not have to 3rd level normalize EVERY thing in a db. >> >> Yes, you absolutely *do* have to normalize at least to 3NF. The only >> excuse for a denormalized schema is if you''ve actually *measured* that >> you''ve got a performance bottleneck that denormalization will solve >> (note: in 11 years of Web application development, I''ve never once had >> to do this). > > i think 11 years create u too old school...And I think you don''t know what you''re talking about.> 3fn in web development? our > dude, so if u like problems -))3NF *solves* problems. What problems do you think it creates?> if u use rails, ar- pattern, thinkin in models, not in database schema. > + counter_caches columns (helpfull in development)No! When working with SQL databases, you have to understand and work *with* the database. When working with objects, you have to understand and work *with* the objects. Fortunately, AR lets you do both simultaneously if you know what you''re doing. And counter_cache should be considered a cheap performance hack, nothing more. It''s not necessary from a design standpoint if your data model is correct. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org Sent from my iPhone -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.