A possibly complex find

Rails
1

Hi, I am very new ruby on rails and I need to do what is I think is
quite a complex find and I wanted to get some opinions on how to do it
in a way that doesn’t hog resources.

My tables look like this :

CREATE TABLE “candidates” (“id” INTEGER PRIMARY KEY AUTOINCREMENT NOT
NULL, “first_name” varchar(255), “last_name” varchar(255),
“created_at” datetime, “updated_at” datetime);

CREATE TABLE “codes” (“id” INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
“name” varchar(255), “value” varchar(255), “created_at” datetime,
“updated_at” datetime);

CREATE TABLE “candidates_codes” (“code_id” integer, “candidate_id”
integer);

candidates_codes is my intersecting table between a habtm
relationship

I have two groups of codes locations and languages and the code values
are things like French, London, NY

I need to be able to search for candidates based on what language
skills they have and in what location they are in.

The bit I really am struggling on is its needs to be able to work in
two ways ether the candidate speaks German and lives in London and the
second way is the candidate speaks German or lives in London.

I have been playing with find but I can only seem to start getting it
to work by having loads of finds which is going to make the search
slower as the number of candidates increases!

Thanks, Alex

2

Your ‘codes’ smell (Code smell - Wikipedia) more like
tags to me…

You should look at has_many_polymorphs, specifically the tagging
feature.

I use it to great effect, allowing a search based on ALL or ANY of a set
of entered tags.

3

Thanks for your reply.

I see what you mean about tags, is it ok to use only stored tags which
are grouped in different boxes ?

Locations

France
German
USA
UK

Languages

French
English

4

My own usage was just that ‘a tag is a tag’, where yours seem to have
distinct types or classes of tags (location or language).

If those are not editable by a user, then I could see managing the UI
presentation of the tags so they could be separated. If they really are
your tags, you can build the logic to know what is what (with two types,
you only have to keep track of half the tags – if not type A then type
B). You could use this knowledge to separate the tags for UI
presentation and simply (re)combine them for persistence.

Taht would let you leverage the tagging portion of has_many_polymorphs.

Of course, that notion falls apart if the users can add their own tags.

5

Thanks, I will give this a try!

Alex