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:
-
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. -
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