#habtm

Связь has_and_belongs_to_many создает связь многие-ко-многим с другой моделью. Например, ваше приложение включает подарки (gifts) и сладости (sweets), где каждый подарок включает в себя много сладостей, и каждая сладость встречается во многих подарках.

Создаем две модели:

rails g model sweet title:string rails g model gift name:string

Выполним миграцию:

rake db:migrate

Создадим новую миграцию для соединительной таблицы:

rails g migration create_join_table sweet gift

Проверьте, что ваша миграция выглядит правильно:

class CreateJoinTable < ActiveRecord::Migration  def change    create_join_table :sweets, :gifts do |t|      t.index [:sweet_id, :gift_id]      t.index [:gift_id, :sweet_id]    end  end end

Выполните миграцию:

rake db:migrate Теперь добавьте связи к моделям:

# models/sweet.rb class Sweet < ActiveRecord::Base  has_and_belongs_to_many :gifts end # models/gift.rb class Gift < ActiveRecord::Base  has_and_belongs_to_many :sweets end

Использование связи HABTM

Запустим rails console:

rails c

Создадим экземпляр модели Gift:

gift = Gift.create(name: "For Udjin")

Создадим новую сладость, которая окажется в подарке:

gift.sweets.create(title: "Chocolate")

Создадим новую сладость без привязки к подарку.

sweet = Sweet.create(title: "Cake")

Положим сладость в подарок:

gift.sweets << sweet

Поздравляю, теперь можете подарить подарок.

Постойте, этот chocolate выглядит так вкусно.

Давайте оставим его себе:

gift.sweets.delete( Sweet.find_by_title(’Chocolate’) )

Проверим сколько сладостей осталось в подарке:

gift.sweets.map(&:title)

There is a pattern I've run into a few times on my current project, and it's caught me a little bit every time. It's simply the problem of joining with multiple objects across a HABTM relationship.

As an example, consider a simple habtm relationship:

With this a lot of questions I might want to ask are already covered. From a Post, I can ask what Categories it belongs to, and vice versa:

The hiccup I've been hitting is asking the question:

Give me all the products in several different categories.

The solution I've been favoring looks is to create an "in_record" scope to perform the join. It looks like this:

Afin d'enregistrer les valeurs dans un ou plusieurs champs d'une table de jointure on procède par ajouter un tableau à $this->data qui a comme nom le nom du model de jointure ex: $this->data['PostsTag'], puis dans ce tableau on insère le ou les éléments tel que suivant :

/* $tags est un tableau contenant les valeurs du/des Tag reçu par la vue, un tableau a été utiliser pour des raisons de simplicité, biensur il faut adapter l'exemple à votre cas */

$tags = /* les valeurs reçu depuis la vue */;

            foreach($tags as $e){                 $tmp = array();                 $tmp['tag_id'] = $e['id'];                 $tmp['status'] = $e['status'];                 $this->data['PostsTag'][] = $tmp;             }

            $this->Post->bindModel(array('hasMany'=>array('PostsTag')));

            $this->Post->saveAll($this->data);

remarque on a pas ajouter la clé étrangère du Post à savoir post_id dans $this->data['PostsTag'] vue que l'id du Post n'est pas encore disponible, au moment de l'enregistrement Cake va l'ajouter ;)

Recently, I've been implementing an admin interface for a system that I want to make more secure than the main application. The way I've chosen to do this is to run some models that relate solely to the admin application (Authentication and Authorization in particular), on a different database - let's call it 'login'.

This seems to be a reasonably common thing to do for security purposes, and also for things like moving data from one database to another. Once again though, I've been tempted into the potential nest of bugs that is has_and_belongs_to_many - let me explain the schema first though:

Administrators table - holds email, encrypted passwords and other data about administrators

Roles table - holds the name of the role - used to authorizing an administrator when performing an action.

Each of these tables uses the line establish_connection 'login' to connect to a different database than the other models - this is the secure database that I want to leave purely for the administrative application.

So, given that I had an administrator that should be given multiple roles, and obviously each role could have many administrators, has_and_belongs_to_many seemed the obvious candidate - I didn't really want a model just for the association, and I would just need to write a migration to create the join table. So, off, I went, and here's what happened:

ERROR: relation "administrators_roles" does not exist

i.e. - the Administrator table exists, and the Role table exists, but the join table just isn't there. The first call for me was to take a look in the database, and make sure that the table was there - which it was - and that migrations had definitely run correctly and the schema was correct - which they were.

After much frustration, I found this thread which described the problems I had been having - and I was vaguely satisfied to see that the problem wasn't really my fault. It seems that in some versions of Rails, ActiveRecord's has_and_belongs_to_many_association class doesn't respect the database connections that the models are trying to use - instead, it uses the universal database connection to try and look up the join table - so, what was going wrong was that ActiveRecord was looking in the development environment's database, when it should have been looking in the login database.

Just finished a new site (well as much as I could do considering the client failed to give me all the relevant content on time)

The content is pretty basic, but I managed to utilise rails to handle alot of the processing.

Public Features

Browse pages

submit form for enquiry

Admin Features

CRUD Pages (with wysiwyg editor)

CRUD Content Blocks (static content items across the site)

CRUD Clients & Client Types (categories)

Manage Admin Users

CRUD + Clone Newsletters

Filter Newsletters by Client Types and only send to active clients that fit that specification

I know it seems like it wasn't much for 2 weeks work but the HABTM between client types and newsletters was driving me nuts for a while but thanks to Ryan Bates (yet again) I managed to get it down pat.

However, I never consider this to be time wasted. Duplication of this project's logic would only take 2 days from here on (excluding precious front-end design time of course).

The content is not 100% yet, but you can see the site at http://www.totallycovered.net.au/

Keep on rails-ing.