Forum: Ruby on Rails Delaying table attribute load using ActiveRecord

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Laurent L. (Guest)
on 2006-04-02 14:19
Hi all,

I came accross the following problem lately: I got a table with several
BLOB fields (Oracle DB) and I have ActiveRecord reading those fields
whenever records are loaded using finder methods. This behavior is just
fine in 99.9% of the time, but considering BLOB data is not small, it is
considerably slowing down search access :(.

So basically, I thought about building a :has_one relationship and add
an extra table table holding BLOB value so as to cope with the pb. I
found it painfull and not very 'RoRy', so I decided to hack
ActiveRecord::Base so as to delay the attribute load... and it works.
Attributes are dynamicaly loaded whenever client application accesses
them explicitely.

Syntax looks like the following:

class A < ActiveRecord::Base
  delay_attributes :foo, :bar
...
end

Now I got two questions:
 - as I am new Rails (and Ruby as well): I am wondering if I am missing
something concerning ActiveRecord usage (meaning this hack is useless),
 - if this patch is a good idea, I'd like to submit it to the
maintainers of the project, but I don't know hat is the exact procedure
to do so.

Thx
Wilson B. (Guest)
on 2006-04-03 18:11
(Received via mailing list)
On 4/2/06, Laurent L. <removed_email_address@domain.invalid> wrote:
> found it painfull and not very 'RoRy', so I decided to hack
>
> Now I got two questions:
>  - as I am new Rails (and Ruby as well): I am wondering if I am missing
> something concerning ActiveRecord usage (meaning this hack is useless),
>  - if this patch is a good idea, I'd like to submit it to the
> maintainers of the project, but I don't know hat is the exact procedure
> to do so.
>
> Thx
>

You can use the new scoped finders with the :select option to prevent
ActiveRecord from pulling in the BLOB column.  You could then make a
separate accessor method to grab the BLOB when you need it.
Laurent L. (Guest)
on 2006-04-04 10:59
Wilson B. wrote:
> On 4/2/06, Laurent L. <removed_email_address@domain.invalid> wrote:
>> found it painfull and not very 'RoRy', so I decided to hack
>>
>> Now I got two questions:
>>  - as I am new Rails (and Ruby as well): I am wondering if I am missing
>> something concerning ActiveRecord usage (meaning this hack is useless),
>>  - if this patch is a good idea, I'd like to submit it to the
>> maintainers of the project, but I don't know hat is the exact procedure
>> to do so.
>>
>> Thx
>>
>
> You can use the new scoped finders with the :select option to prevent
> ActiveRecord from pulling in the BLOB column.  You could then make a
> separate accessor method to grab the BLOB when you need it.

Thanks for your quick and accurate answer :)

I guess you are right, scoped finders can do the job pretty well.
However, I have still to specify the scope in every calls to the
repository (could be error prone) and take care of some accessor (even
if it is no big deal though). While scoped finders mainly dynamically
adapt queries given the runtime context (for security purpose mainly),
delaying some table attribute load is rather a static behavior, non
context oriented and a good workaround for coping with large columns
slow access.
As my application is not very big now, I'll try to use both approaches
to see whether it is still a good idea to have ActiveRecord::Base
patched or not (which sucks a lot cause I have to scratch my head every
time activerecord is released!).
This topic is locked and can not be replied to.