Remove database layer abstraction

[mehulkar]

Opening this up for discussion. Prompted by @tjgrathwell's PR to remove votes in #280.

---

What do you think of abstracting the role of databases into a new/optional section of the curriculum? We could provide a downloadable .sqlite3 files or even a web API to make this abstraction possible.

I typically don't introduce the Model/database layer until the very end of the curriculum. In the controller, I usually start by assigning @topics to "some random text" rendering it in the views and changing it to @topics = Topic.all later. Treating the data store like a black box not only simplifies the curriculum, it also follows the current popular pattern of consumable APIs in web dev.

[lilliealbert]

I'd rather cover databases very briefly than abstract them away. What's the win in abstracting them? I'm worried that students will leave thinking the DB isn't something they can organically interact with if we provide them an unrealistically abstract representation.

BTW, Travis isn't removing votes, he's just restructuring the way the Suggestotron app is structured. Not sure if you grokked his PR.

[mehulkar]

Ahh, I did misunderstand that. I thought he was removing the Votemodel and replacing it with a votes_count integer field on the topics table that would be incremented/decremented.

The win in abstracting the db layer is that it's not that important. All the student needs to know is that dataz are stored somewhere and a Rails application can access them.

Explaining tables is decently simple because people are familiar with spreadsheets. Relationships, not so much. I think it's a time sink with a negligible win.

[rachelmyers]

I usually feel like we should explain more about what's going on in Active Record; that tables in the database correspond to our AR classes, and following that convention keeps us from having to explicitly connect elements in the database with our ruby objects. It's probably not worth showing alternatives in depth, but I could see using the Data Mapper pattern as a way to walk people through how we would get data into our objects without Active Record.

My main motivation is that I think people who have repeated several workshops don't understand the difference between the code and the database, or how stored data gets pulled into objects and put back again. :confused:

[rachelmyers]

Sorry for accidentally closing!

[mehulkar]

@rachelmyers My approach here is to aggressively simplify the curriculum for a 1 day workshop so that students leave less exhausted and overwhelmed. Abstracting the database layer, especially in the Beginner classes, is an easy way to do that since ActiveRecord can be so easily ignored when demonstrating the Rails pattern.

I've also seen students not understand the difference between the code and the database. For me, this is even more of a reason to simply remove the source of confusion.

[rachelmyers]

Yeah, we should definitely simplify if extraneous explanation is a source of confusion. My suspicion is that the confusion comes from a lack of explanation.

But the implementation is always key; so maybe we can open PRs and see how these ideas work in practice. :horse_racing:

[alexch]

I'm with Rachel&Lillie. The main point of RB is to remove the magic so people can think "the data gets stored in this actual thing called a database" and get at least a vague idea how they work. Relations are not extra; they are essential, but if people don't grok it the first time it's not a huge deal.

[rachelmyers]

Once upon a time @alexch taught the novice class by spending the majority of time with plain ruby and then creating a Sinatra app out of it. If the focus for novices should be learning the language, let's leave persistence out entirely.

As soon as we start doing Rails, let's explain the database clearly. :sunny:

[alexch]

And I did it again! See http://codelikethis.com/lessons/learn_to_code and http://codelikethis.com/lessons/learn_to_code/sinatra (I wrote all new slides when I taught for GDI last summer; RailsBridge can use them too.)

On Nov 26, 2013, at 6:23 PM, Rachel Myers notifications@github.com wrote:

Once upon a time @alexch taught the novice class by spending the majority of time with plain ruby and then creating a Sinatra app out of it. If the focus for novices should be learning the language, let's leave persistence out entirely.

As soon as we start doing Rails, let's explain the database clearly.

— Reply to this email directly or view it on GitHub.

[tjgrathwell]

Removing database stuff from the standard Rails intro seems like bad news. Additional ruby/sinatra/whatnot curricula options are always welcome, regardless of how much or little they plan on focusing on the database. Closing this thing. Happy holiday! :gift: