Existing magic to prevent db redundancy?


#1

suppose users have a favorite colour, linked to with a color_id field.
suppose also they have a pet rock, which is one of many possible
colors…

is there a ‘best practice’ in order to avoid having ‘blue’ appear in the
Color table 100 times. can validates_uniqueness_of be twisted into
handling this case? should i be adding something to the initialize()
method of Color to search for itself and return an existing one if the
name matches? perhaps set the unique attribute right on the color table
in the DB and handle inserts with rescue that returns an existing
record? just looking for a pointer in the right direction. obviously any
solution to this is a few lines at most but i am wondering if i didnt
just miss some built-in AR magic or if someone has a preferred
technique…


#2

On Monday, May 22, 2006, at 10:18 PM, cdr wrote:

record? just looking for a pointer in the right direction. obviously any
solution to this is a few lines at most but i am wondering if i didnt
just miss some built-in AR magic or if someone has a preferred
technique…


Posted via http://www.ruby-forum.com/.


Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails

Try ‘has_and_belongs_to_many’ (habtm)

rocks
id
user_id
name

colors
id
name

colors_rocks
color_id
rock_id

Rock habtm colors
Rock belongs_to user
Color habtm rocks

pet = Rock.new << Color.find_by_name(“Blue”)
pet.save

If you wanted to make sure the rock was only one color, you could clear
the associations before making a new one.

_Kevin


#3

The standard way of handling this is a has_and_belongs_to_many
relationship.

This means that many users associate with blue, and blue associates
with many users.


| users | -------< | colors_users | >------- | colors |


                | color_id     |
                | user_id      |
                ----------------

Rails supports this via has_and_belongs_to_many, but it’s
really a relational database concept that is supported by
Rails, i.e. the concept existed well before Rails. :slight_smile:

You can create as many join tables against colors as you
need. In your example, you’d need the one against users
as shown above (to handle the users’ favorite colors),
and another against whatever table associates pet rocks
with that user.


– Tom M.


#4

Greetings,

I’m trying to test some of my controller’s protected methods and I’m
wondering how other folks handle this.

Should I be testing protected methods?

I’ve tried searching with google on this topic and not much has turned
up. If anyone knows about good articles
on this subject, that would also be appreciated.

-Steven


#5

Tom M. wrote:

thanks for your prompt response (Kevin also) . actually ive got a
polymorphic join table to associate the colors to where they need to go
(actually theyre Locations, and i wanted to avoid excessive geolocation
lookups), but was wondering if there was some kind of find_or_create().
and i see something about it in the AR changelog and as a convenience
function in Typo… so. next time i must just think ‘what would the
rails method be called if it existed’, and try it in irb…

ps you got a Figlet thing to generate those diagrams?


#6

On May 22, 2006, at 03:35 PM, Steven H. wrote:

I’m trying to test some of my controller’s protected methods and
I’m wondering how other folks handle this.

Should I be testing protected methods?

Obviously, the answer to that is, “you should always test all of your
applications behavior.” ;->

Now, as to how to go about this, for protected/private methods, it’s
not really that hard. They key thing is you can’t test those methods
directly, since you can only call them from within the Controller
class. Hopefully, your protected method is generating or setting an
instance variable or session value. All you need to do is test the
value of that data as part of one of your functional tests. If your
method returns different data, based on the action that calls it,
then you’ll need to test those additional return values in the
appropriate functional test methods.

One last thing… if your protected method is performing a standard
operation on a model class, you might want to look into moving that
behavior out of the controller and into the model class. That way,
you can easily Unit Test it. I generally try to keep my functional
tests to verifying templates, redirects and assert_tag values. If I
need to generate specific data that’s used across several controllers/
actions, hopefully that data is coming from one of my model classes,
so that I can test it irrespective of where it might be accessed.

-Brian


#7

On May 22, 2006, at 2:19 PM, cdr wrote:

ps you got a Figlet thing to generate those diagrams?

Nope, just years of experience, and enough years behind
me to be patient enough to knock them out. :slight_smile:


– Tom M.