плохо только что не используется в production и не stable:
we've added Rails 3.1/3.2 support, but until further notice we consider it a beta-quality feature since we do not run any production software on this version of Rails.
Не уверен на счёт того что id пользователя в социальной сети можно считать действительно случайным числом с равномерным распределением. С таким запросом у некоторых пользователей будет гораздо больше вероятность вытянуть жребий. Например если количество пользователей в этой сети росло не линейно (а так обычно и бывает). Отсортируйте id по возрастанию и сравните id(n) — id(n-1).
Теперь всё «в порядке». Было какое-то взаимонедопонимание с саппортом.
Приводил им примеры Graph которые не работают, в ответ через 1 день получал извенения или «странно. у нас всё работает».
(это и заставило меня написать вопрос на хабре — стало интересно неужели они сами не замечают что их graph не работает толком).
Но сейчас наконец-то написали «I am sorry about this. Network graphs are not updating in real time. We want to improve this in the future though.»
Хозяин — барин. Хотя это как посмотреть. В новой версии могу измениться зависимости (и соотв. порядок загрузки), следовательно нужно будет следить за этим и иметь целую сущность «порядок загрузки». Могут понадобиться циклические зависимости. Если будет какой-то сбой и что-то пойдёт не так — придётся все машины останавливать и заново запускать (чтобы наверняка заработало). Вместе с тем новый баг в коде реконнекта при старте уже отлаженного сервиса мне кажется маловероятным.
Хоть поясните какими языками программирования владеете, и опишите опыт в программировании, в следующих технологиях — xml, regexps, http (libcurl итд), http — знание протокола, mysql.
не знаю создан или нет, если будете реализововать — и будут конкретные проблемы — обращайтесь, гляну код, помогу советом (исходники показать не имею право, но клиент недавно объявился сообщил что моя программа (c++, win32) работает rock solid на многих компах уже 6 лет). с perl серверами тоже опыт большой.
В общем случае задача может быть вообще не решаемой автоматически, без участия человека. В частном случае нужно знать какой объём и какие именно изменения там есть, а потом решить писать ли скрипт или лучше руками переделать в миграции (и финальную структуру БД использовать для проверки корректности миграций).
Есть ли программы, автоматизирующие эту деятельности — не знаю. Но я бы не стал пытаться решать это «малой кровью».
удобно, неудобно. это же в одном месте можно закодировать. потом только иметь дело с понятиями «не аутентифицированный пользователь» и «аутентифицированный пользователь», ничего не зная про сессии. авторизация отдельно от аутентификации.
we've added Rails 3.1/3.2 support, but until further notice we consider it a beta-quality feature since we do not run any production software on this version of Rails.
есть ещё проекты
github.com/tchandy/octopus
github.com/wbharding/seamless_database_pool
по ним тоже нельзя сказать что они работают нормально.