Ruby On Rails

Greetings Mate!!! In this article,   you'll learn about REST and how Rails implements it.   REST is a tricky subject in beginner   Ruby on Rails training.   On one hand, it requires learning   some advanced web concepts and new techniques   at a time when you're still getting   your footing in the basics of MVC and CRUD.   But on the other hand,   REST has become such a core part   of developing in Rails that you must learn it.   So hang with article as you go into some deeper waters.   REST is short for Representational State Transfer ,   and REST is a design concept   which says that our application   should not focus on performing procedures,   but instead on performing   state transformations upon resources. It's not easy to see how that's   different from what we're already doing   because the Rails MVC pattern   already encourages us to break up our code   by model and c...

Greetings Geek, In this article, we're gonna add more complexity   to our join tables.   I call these rich joins.   First, to understand why we need this complexity,   let's go back to the many-to-many diagram   for the beginning of this chapter.   This is a classic many-to-many example.   We have a number of courses,   we have a number of students taking these courses.   There will be a table named courses   and a table named students, and in the simple join,   we would have a join table between them,   which we would call courses_students. In the join table will be two foreign keys,   one for the course, and one for the student.   Here's where the simple join falls short, though. Imagine that we wanna keep track of more information   than just the fact that a student   is participating in a class.   You might wanna keep track of their seat number,   or the date they signed up,   or the...

Greetings Geeks, We'll begin by looking at a simple join,   and then move on to a more complex join in the next movie.   Many-to-many associations are similar to one-to-many   associations because they also have an object   which has many objects which belong to it.   The difference that as a many-to-many,   the objects don't belong to it exclusively.   For example, a project   has_and_belongs_to_many :collaborators.   The project can have many collaborators,   but the collaborators can also have many projects. It's not like the project owns a collaborator exclusively.   They're allowed to work on other projects, too.   You have a Blog Post, which  has_and_belongs_to_many :categories.   If our Blog Post is both in   the technology and training categories,   it doesn't mean that no other Blog Post can be   in the technology and training categories.   Technology will have many Blog Posts. ...

Welcome,  First, consider   when you might actually use a one-to-one association   because there are two main use cases.   The most common reason is for unique items   that a person or a thing can have only one of.   For example, an employee has_one : office   or a student has_one : id_card .   The ID card is unique.   It belongs only to this one student   and to no one else.   And that student is only allowed to have one ID card.   It's certainly possible to imagine a scenario   where an employee might have two offices. But by using a has_one relationship,   we're rejecting that possibility in our design.   We've made it a statement of fact   that each employee can have only one.   At the point that we want to allow employees   to have more than one,   we would need to revise our relationships to match. The second reason to use a one-to-one relationship   is to break up a sing...