Ruby on Rails + legacy_migrations: односторонняя синхронизация данных между двумя проектами

[@zayko]

paperclip => carrierwave
было бы интересно

[@Antiarchitect]

Дело в том, что ситуация гораздо плачевнее и на старом проекте в некоторых местах используется это. Посмотрите на год последнего коммита и посочувствуйте.

[@UseRifle]

OldNewsDoc.each do |old|
  if old.image
    new = NewsDoc.find old.id
    new.image = open(old.image.path)
    new.save
  end
end

Ну и rescue воткнуть на всякий

[@icesik]

Интересно, а нельзя было сделать проще? Т.е. плавно двигаться в будущее. Зачем начинать именно новый проект и перетаскивать туда всё? Почему нельзя было обновить rails до последней 2.3.x версии, починить все ворнинги, потом поменять структуру базы миграциями так как надо, заменить mysql на postgres (если так охота) и мигрировать на rails 3?

[@Antiarchitect]

Да вы прям фантаст! Начнем с того, что изначально проект писался на rails 1.2 и некоторая его часть сейчас — это просто мертвый груз. Второе — проект использует части другого полумертвого проекта и вынужден соединяться со сторонней базой — это необходимо устранить, ну и третье — проект не имел здорового жизненного цикла, поэтому во многом код представляет собой абсолютное месиво.

P.S. Абсолютно везде — во view, model и controller присутствует русский язык — еще один фактор.

[@asci]

Почему солр вместо сфинкса выбрали?

[@Antiarchitect]

Честно говоря, сначала я польстился на особенность гема sunspot_rails Который для разработки не требует никаких дополнительных установок — все работает из коробки (я так подозреваю, что для продакшн придется ставить полноценный Solr). Плюс у Solr есть некоторые преимущества перед Sphinx одно из которых лучшая реализация faceted search, который упрощает жизнь при необходимости продвинутого поиска на проекте.

[@benone]

А чем она лучше сфинксовой-то на Ваш взгляд?

[@benone]

Реализация фасеточного поиска