self-modifying rails model

[eddiewould]

Hi, I want to write a rails application which is being used for querying a research database. It would be nice if the users (at least admin users) could add extra paramaters (variables) to the database, as time progresses. Mostly these will be stored in a table.

What I want to know, is what is the feasibility of allowing the user to do the following: create a new table in the database, a foreign key link to that table in the database (from the main table), and have rails modify the model of corresponding to the main table, to reflect the newly added foreign key (has_a relationship).

Your thoughts / opinions / ideas greately appreciated!

Eddie

[rob]

Wow..

Well, in my experience, self modifying code always has a set of challenges that aren't there with normal code. Of course, there's a fair amount of security issues that would have to be addressed in any implimentation, but if there was any language that would make it easy, Ruby would be it.

Perhaps using a distributed Ruby backend where an Active Record model keeps getting added to, and upon termination of the script the object gets serialzed and saved, and reloaded would be a potential way to go?

Of course you could just write to the file, but then if you're dealing with FCGI you'd have to reload the interpreter.

I dunno.. just some thoughts.

[eddiewould]

I'll be more specific about what I'm trying to achieve. The system will
be used by med students, who basically enter patient/consultation
details, come up a hypothesis (basically correlating symptoms and
patient variables to a diagnosis) and then using the database to test
the hypothesis, looking at the frequency with which the various
diagnoses occur, given the set of conditions (symptoms present, patient
variables).

Depending on what the students decide to use as their hypothesis, they
may wish to examine things which have not been looked at in previous
years. Two which came up this year was 'Flu-Vaccine' relating to when
the patient last had a flu vaccine. The options for this are stored in a
table with simply an id and a value - 'Never', 'Unknown', 'This year',
'Previous'. This is table is linked to from the Consultations table via
a foreign key. Likewise, there is a table 'SmokingStates' with values
'Ex', 'Current', 'Never' & Unknown.

In the future, perhaps the course administrator would like add a
variable 'Ethnicity'. This would need to be created as another table,
with simply two fields - id and value. There would be rows in the table
for the options for ethnicity, and we would need to add another field to
the Consultations table, which is a foreign key referencing to the value
for ethnicity.

The SQL side of this isn't going to be a problem - rails provides a way
to execute raw SQL, but perhaps more of a challenege is going to be
updating the rails models to reflect the new relationships.

Surely someone has tackled this kind of problem before?

Thanks very much for you ideas
Eddie

[bluetechnx]

well, I havent done this in Rails persay...but have worked with database schemas exactly like that withh PHP/ColdFushion/MsSQL applications.

Your main idea is you have *alot* of crossreferencing between tables and there can be many types of of choices for a given reference (like your ethnicity example).

I would suggest that the "Consultation" table be very generic. Table schemas should not change often (Except between versions of a project). Perhaps the Consultation should (1) contain all personal info with a foreign like to a user_id (and a user table holding user details (2) a consultation id holding an fkey to a consultation table with itself holding foreign keys to say "sickness types" and "sickness occurence rate" (weekly, monthly, last year, this year).

...I guess my main point is. 'General' topics like Ethnicity *should* be in the schema as a fkey to another table and that _other_ table should hold the values of Ethnicities (eww spelling) so that IT can be easily modified...

I dont know if this helps. I agree such schemas are ugly to work with (and a nightmare to debug) because you tend to be staring at smokingStateXref which is usually an Integer id.

Your job might be easier if you can make larger Xref (I mean 'crossreferencing') tables that link a table to a larger idea (like Consultation) with other tables, like "Types of Sickness", "Types of Symptons" ...it all about a good schema I guess :/

[eddiewould]

Hey Bluetechnx

Sorry I might not have made it clear in my previous post - but things such as Ethnicity will *definately* be in a seperate table , just like SmokingStates and FluVaccineStates currently are in seperate tables. This way if new ethnicities are needed it will simply be a matter of adding a new line to the table.

The problem I'm more concerned with is making the rest of the models 'aware' of these newly added tables.

The only real solution I can think of, is to have a "table of tables" ie a 'god' table which knows about all the other tables (their name, and their referencing foreign key).


Your thoughts?
Eddie

[motobass]

I am wondering whether all the extending you will need to do can be easily accomplished by look up tables of the kinds you provided examples of. If so, than maybe you can do something along the lines of using the Single Table Inheritance to make it happen.

class EthnicityDiagnosisFactor < DiagnosisFactor
end

class DiagosisFactor < ActiveRecord::Base
...
end

That way, you have a single diagnosis_factors table, set up just so. When someone adds a new type, the new class name should be relatively easy to come up with. Write the model file out like any other file. I guess you'll need a basic admin for it, etc.

Disclaimers: I have no idea how practical this is, or whether this new models would ever appear in a running production app. Like Rob said, it may require some futzing with FastCGI processes.

http://wiki.rubyonrails.com/rails/pages/ForumExample