vsuhachev

есть следующие варианты:

1. прописать в DNS для subdomain.clientwebsite.ru ip-адрес вашего сервера
   
2. настроить прокси с clientwebsite.ru на ваш сервер
   

для вашего запроса не нужны связи, вот ка-то так

Call.where('CallContragent' => 123).or.where('CallContact' => [123, 123, 123]) # rails 5
Call.where('CallContragent = ? OR CallContact IN ?', 123, [123, 123, 123]) # rails 4

А вообще в модели Call судя по всему должно быть

belongs_to :client
belongs_to :contact

А в Client

has_many :calls
has_many :contacts, through: :calls

В Contact - что-то аналогичное тому что с Client, только для вызовов и клиентов

list.sort { |a,b| a['plan']-a['present'] <=> b['plan']-b['present'] }

connect нужен для того чтобы подписать компонент на события редуцера и дать доступ к данным редуцера. А роутинг он вообще в стороне от redux (хотя, конечно, есть роутеры, работающие через redux).

Я обычно придерживаюсь следующего: connect применяю к компонентам-контейнерам верхнего уровня, которыми управляет роутер(в вашем случае это Component-1, Component-2). Во все остальные простые (dumb) компоненты, находящиеся в контейнере, данные получают в параметрах (через props) от контейнера.

Если вложенные компоненты должны как-то взаимодействовать с redux: для этого в компоненте-контейнере определяются функции, которые видят редуцеры и dispatch. Дальше эти функции отдаются dumb-компонентам через props и они их могут вызвать по какому-то своему событию.

Теоретически вы можете делать connect к любому компоненту, но во первых это более накладно по ресурсам и во вторых это убивает инкапсуляцию. Прелесть т.н. "тупых" компонентов в том что они простые и зависят только от явных параметров (props) и следовательно легко переносимы. Добавляя к ним connect мы прибиваем их гвоздями к модели данных конкретного приложения.

Вам нужно делать такую миграцию в 4 этапа:

1. создаете колонку с типом datetime с временным имененм
   
2. из колонки с типом string переносите данные в колонки с datetime
   
3. удаляете колонку с типом string
   
4. колонку с типом datetime переименовываете в нужное имя
   

И относительно вашего кода по переносу данных - так делать не рекомендуется потому что во-первых это крайне медленно, во вторых миграция зависит от класса. Представьте, через некоторое время вы доработаете класс(например переименуете аттрибут query_date) и ваша миграция перестанет работать т.к. она рассчитывает на то что код класса Page не поменялся, а он поменялся.

Для того чтобы миграции не зависели от кода классов и не отваливались со временем нужно писать их на SQL.

execute('update pages set new_query_date = STR_TO_DATE(query_date)')

Универсальных решений нет т.к. все очень сильно завязано на приложение, его архитектуру и схему развертывания. Обычно в простых случаях восстановление делается руками, в сложных пишется скрипт.

Из своего опыта могу сказать, что такие скрипты быстро протухают и запуск такого скрипта через полгода-год это фактически опять отладка и дописывание скрипта вперемешку с эмоциями "какой $#% это писал". В связи с чем часто приходит мысль - "а может все-таки руками проще??"

Считается плохим тоном добавлять слишком много кода во view. Если этот код логически относится к контроллеру или модели то нет проблем - размещаете его там. Но иногда есть код чисто для представления. Например вам нужно отобразить список тэгов с локализацией.

I18n.t(tag, scope: "very.very.very.very.very.very.very.very.long.string.#{product.category}", default: tag.to_s.humanize)

Вы конечно можете разместить такой код в пердставлении

<%- product.tags.each do |tag| %>
  <p>
    <%= I18n.t(tag, scope: "very.very.very.very.very.very.very.very.long.string.#{product.category}", default: tag.to_s.humanize) %>
  </p>
<%- end %>

А можно убрать его в хэлпер

def localized_tags(product)
  product.tags.map do |tag|
    I18n.t(tag, scope: "very.very.very.very.very.very.very.very.long.string.#{product.category}", default: tag.to_s.humanize)
  end
end

И тогда вы получаете первое преимущество: читаемый код вьюхи

<%- localized_tags(product).each do |tag| %>
  <p><%= tag %></p>
<%- end %>

И второе преимущество: вы можете переиспользовать localized_tags, написать на него тесты и т.п. И ваши модели и контроллеры не засоряются логикой представления.