Hello, I don''t know anything about Rails optimization, however... is it possible to select only specified columns in order to tell Active Record not to load everything from the table as does @items Item.find(:all) ? Thank you
Jérôme L wrote:>Hello, > >I don''t know anything about Rails optimization, however... is it >possible to select only specified columns in order to tell Active >Record not to load everything from the table as does @items >Item.find(:all) ? > >See find_by_sql()
Steve Downey wrote:> Jérôme L wrote: > >> I don''t know anything about Rails optimization, however... is it >> possible to select only specified columns in order to tell Active >> Record not to load everything from the table as does @items >> Item.find(:all) ? > > > See find_by_sql()But you better not go down that route unless you have a clearly identified performance problem. Dealing with half-instantiated objects is pain. Alex
Alexey Verkhovsky wrote: > Steve Downey wrote:>> Jérôme L wrote: >> >>> I don''t know anything about Rails optimization, however... is it >>> possible to select only specified columns in order to tell Active >>> Record not to load everything from the table as does @items >>> Item.find(:all) ? >> >> See find_by_sql() > > But you better not go down that route unless you have a clearly > identified performance problem. Dealing with half-instantiated objects > is pain.Having this functionality would be rather useful, as I''ve decided against using AR for BLOBs, and I''d like to stop using it for hashed passwords, because I don''t want the overhead (and risk) of fetching them when I don''t need them, as well as having to see all that binary/secret data in the logs when I do an update, even when I''m never changing that column. It would be nice if you could define (in the model) certain columns to *not* fetch, at least by default. You could then have lazy fetching/updating in the attribute methods, and/or force a fetch with find(:include). I''m surprised that AR doesn''t do it this way already. Isn''t it obvious that you don''t want to select all of the columns all of the time? Or am I missing something? -- Steve
Most objects are small enough that you don''t care; For bigger ones that needed custom fetching to avoid loading too much (case in point-- I had an Image class that stored in the db tiny, med, large versions. I didn''t want to load all of the large ones when displaying a page full of tiny thumbs), I''ve used find_by_sql. ActiveRecord is an ORM--half-instantiated objects are kind of a no no in ORM''s and lazy loading for everything by default is a performance nightmare. It might probably be a good idea to have a lazy marker for columns and some sort of argument to find that let you include/exclude columns, but that would mean that all AR-fetched objects weren''t created equal which would be a pretty large invariant break. By forcing users to get partially-instantiated objects from functions with names other than ActiveRecord#find, you''re forcing the person writing the controller code to be aware of the missing pieces of their objects each time they look at the block (rather than it being buried in arguments to find, which are less likely to be read when simply scanning the code). I''ve had desires like this from time to time (esp. with regard to joins where I''d like to mark something for inclusion by default or something), but I don''t know if I like the idea of making find even more of a kitchen sink than it already is. Brian On 8/20/05, Steve Sloan <steve-2FdKsI0tZ45AfugRpC6u6w@public.gmane.org> wrote:> Alexey Verkhovsky wrote: > > Steve Downey wrote: > >> Jérôme L wrote: > >> > >>> I don''t know anything about Rails optimization, however... is it > >>> possible to select only specified columns in order to tell Active > >>> Record not to load everything from the table as does @items > >>> Item.find(:all) ? > >> > >> See find_by_sql() > > > > But you better not go down that route unless you have a clearly > > identified performance problem. Dealing with half-instantiated objects > > is pain. > > Having this functionality would be rather useful, as I''ve decided against > using AR for BLOBs, and I''d like to stop using it for hashed passwords, > because I don''t want the overhead (and risk) of fetching them when I don''t > need them, as well as having to see all that binary/secret data in the logs > when I do an update, even when I''m never changing that column. > > It would be nice if you could define (in the model) certain columns to *not* > fetch, at least by default. You could then have lazy fetching/updating in the > attribute methods, and/or force a fetch with find(:include). I''m surprised > that AR doesn''t do it this way already. Isn''t it obvious that you don''t want > to select all of the columns all of the time? Or am I missing something? > > -- Steve > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- The years ahead pick up their dark bags. They move closer. There''s a slight rise in the silence then nothing. -- (If you''re receiving this in response to mail sent to bluczkie-OM76b2Iv3yLQjUSlxSEPGw@public.gmane.org, don''t be concerned This is my new address, but mail will be forwarded here indefinitely)
On Sun, 2005-08-21 at 15:36 +0000, Brian L. wrote:> Most objects are small enough that you don''t care; For bigger ones > that needed custom fetching to avoid loading too much (case in point-- > I had an Image class that stored in the db tiny, med, large versions. > I didn''t want to load all of the large ones when displaying a page > full of tiny thumbs), I''ve used find_by_sql.This points out where you could have restructured your db and class and fix that problem. This of course ignoring the. imo, bad idea of storing the pictures in the db. Class ImageDetail has_one :med, :class_name => ''Image'' has_one :large, :class_name => ''Image'' has_one :tiny, :class_name => ''Image'' end This lets you get just the images you need. Also it allows you to do quick searches in the details without requiring the db to scan past all the image files.> > Having this functionality would be rather useful, as I''ve decided against > > using AR for BLOBs, and I''d like to stop using it for hashed passwords, > > because I don''t want the overhead (and risk) of fetching them when I don''t > > need them, as well as having to see all that binary/secret data in the logs > > when I do an update, even when I''m never changing that column.While this was an unintended benefit of a different decision, but separating the login information from the person information helps keep you from needing to ever load the hashed password from the database. Once authenticated, you don''t need to keep doing anything more than validate the login account still exists and is not disabled which is a simple bool look up. The rest of the time you go through the person object to link up records or edit other information. Our different decision was due to needing to maintain people to other links, but wanting to disable and possibly delete the login account for these people. -- Steven Critchfield critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org KI4KTY
> I don''t know anything about Rails optimization, however... is it > possible to select only specified columns in order to tell Active > Record not to load everything from the table as does @items > Item.find(:all) ?the :select option was added to trunk: find :all, :select => ''id, name, title'' I''m not sure if it''s in the latest beta gems or not. I find this really helps with piggybacked queries and joined queries. Sometimes ''SELECT *'' has some wacky results when you''re joining tables. It sometimes grabs the id column of another table and tries to pass that off as the ID of your model. Keep everyone''s good advice in mind about partial objects. If there''s a blob that you don''t want on every query, you''re probably better off using a has_one association. -- rick http://techno-weenie.net