RAILS COMMAND SEE ALL ACTIVE TABLES CODE

Rails, or specifically ActiveRecord, requires that your model classes are a reflection of the database. string 'url' end Plotting a courseĪt this stage, a dilemma presents itself. string 'copyright' end create_table 'exercises' do | t | t. string 'copyright' end create_table 'videos' do | t | t. integer 'content_id' end create_table 'articles' do | t | t.

It would essentially be a join model:Ĭreate_table 'steps' do | t | t. A Step would then be reduced to a (content_type, content_id) reference to a content item, and a course_id and position to place the content in order within a course. We knew that in order to make it easier to add new content types, we wanted each type in its own table.

As an STI table accepts more types, the more it resembles a schemaless document store. However, there is nothing to stop someone (via the console, or via a programming error exposed to users) giving an Article a url. The computer will tell you when you’ve got it right, and will offer you help after you’ve made a certain number of moves. new ( title : 'Ordering Saturn’s moons', body : <<- STR, Put the names of some of Saturn’s moons in order starting with the closest to the planet by dragging the names up and down the list. new ( title : 'Tidal effects on Io and Europa', asset_id : 1, copyright : '© The Open University' ) course. STR copyright : '© The Open University' ) course. Pluto orbits the Sun in an inclined orbital plane, and goes around the Sun twice for every three orbits that Neptune makes. It last crossed inside Neptune’s orbit in 1979. new ( title : 'Pluto’s eccentric orbit', body : <<- STR, !() Pluto’s orbit is so elliptical that it strays inside Neptune’s orbit for 20 years out of its 248-year circuit round the Sun. This is most easily realised if all the steps live in the same table.Ĭourse = Course. So, each content item belongs to a course, and we use acts_as_list to keep the items, or ‘steps’, in order. All these types of content have to be put into a sequence to make a course. After all, articles, videos, discussions and quizzes don’t seem like subtypes of one another. You might be wondering why we went with this design in the first place. In this article, I’ll explain how I broke the table up and how I tricked Rails into letting me do it. All the types of content that make up our courses – articles, videos, discussions, quizzes and so on, ten types in all – were being stored in a single table called steps. One of the first projects I took on after joining FutureLearn was a refactoring of our content model. Fortunately, there are ways to work around this and perform the migration in incremental steps.

Since the entire application is then coupled to the schema, any change to the database ripples through the entire codebase unless you find a way to contain the change. Rails adds to the problem by tightly coupling your model API to the schema, and encouraging you to use this API directly from controllers and views.

RAILS COMMAND SEE ALL ACTIVE TABLES CODE

And, given the number of different types the table stores, it’s quite likely that a lot of your model code is coupled to it. You want to break this giant table into smaller focussed ones, but that will involve moving a lot of data and updating references. You reproduce a lot of work the database would do for you, if you only had each data type in its own table.īy the time this storage model becomes a problem, it can be really hard to see a way out of it. Those types create costs for one another: when you query for articles, you must remember to filter out all the other types of values and to only select columns relevant to articles, or else pay a huge performance cost. Each type of record uses some subset of the table’s columns, and none uses all of them, so you end up with a very sparsely populated table. A common problem with STIĪ common problem with STI is that, over time, more types get added to that table, and it grows more and more columns, and the records in the table have less and less in common with one another. In Rails, the type column is used to determine which type of model to instantiate for each row a row with type = 'Article' will make Rails call Article.new when turning that row into an object. Single-table inheritance (STI) is the practice of storing multiple types of values in the same table, where each record includes a field indicating its type, and the table includes a column for every field of all the types it stores. James Coglan, a Developer at FutureLearn, explains a common problem with STI and how we refactored our Rails app to solve it.

Rails command see all active tables