# Acts\_as\_sugarbean: returning records based on flag in associ

**URL:** <https://www.ruby-forum.com/t/acts-as-sugarbean-returning-records-based-on-flag-in-associ/73628>\
**Category:** Rails\
**Created:** [October 25, 2006, 8:56pm UTC](https://www.ruby-forum.com/t/acts-as-sugarbean-returning-records-based-on-flag-in-associ/73628 "2006-10-25T20:56:31Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![cainlevy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/ecccb3/32.png) [@cainlevy](https://www.ruby-forum.com/u/cainlevy)\
**Post date:** [October 25, 2006, 8:56pm UTC](https://www.ruby-forum.com/t/acts-as-sugarbean-returning-records-based-on-flag-in-associ/73628/1 "2006-10-25T20:56:31Z")

</div>

so i’m developing an acts\_as\_sugarbean module that handles sugarcrm’s  
database structure. for those of you fortunate enough to not know what  
that entails, it means a number of oddities of which the following are  
pertinent:

1. a model exists in two tables: the table with standard fields and a  
table with custom fields setup during deployment. so, for instance, an  
account’s attributes are found in the accounts table and the  
accounts\_cstm table. both tables share a primary key.

2. a model is never deleted. instead, a deleted=1 flag is set in the  
main table.

i’ve developed my acts\_as\_sugarbean module to the point where it will  
set up the main model (e.g. the account) with associations to a related  
\_cstm model. further, the main model proxies the \_cstm model’s  
attributes and dynamic finders, so from a programmatic standpoint you  
don’t need to know that the \_cstm model exists.

that’s all working peachy.

the trouble i’m running into is when i’m searching for records based on  
an attribute in the \_cstm model. the exact problem here is that i  
shouldn’t get any records where deleted=1 in the associated row of the  
/main/ table.

my first attempt at solving this was to define a wrapper for the find()  
method of the \_cstm model which adds an :include flag to induce a join  
statement, then adds :conditions that refer across the join to the main  
table. and that works great … except that it only works for the find()  
method. it doesn’t work for dynamic finders, though, because they bypass  
find() and go straight for the find\_initial() and find\_every() methods.  
which are private.

i can think of a couple possible directions, all with varying levels of  
hackishness.

for instance, when the main model proxies dynamic finders for the \_cstm  
model, it could rewrite them to use the find() method. but that  
duplicates perfectly good activerecord code, and is hardly something i’d  
want to maintain.

or i could try to bypass the privateness of the find\_every() method and  
add my :include and :conditions through a wrapper. but i honestly don’t  
know how to go about doing that, given how find\_every() is attached to  
the model (it’s defined within a “class \<\< self” block).

or maybe someone out there with a better understanding of rails could  
give me another idea?

thanks for reading,  
-lance ivy

---

<div class="post-metadata">

**Author:** ![cainlevy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/ecccb3/32.png) [@cainlevy](https://www.ruby-forum.com/u/cainlevy)\
**Post date:** [October 25, 2006, 9:10pm UTC](https://www.ruby-forum.com/t/acts-as-sugarbean-returning-records-based-on-flag-in-associ/73628/2 "2006-10-25T21:10:32Z")

</div>

hah, i just discovered that `super’ bypasses visibility. i’m going to  
wrap find\_every() from my module and see if i can make that work for  
me.

always open to suggestions on how to handle this better …