Не хочу вступать с Вами в длительную полемику. Объясню просто:
1. Есть рабочая база полугодовой давности.
2. Есть свежая копия профиля с предыдущей системы с побившейся базой.
Ваши пункты 1 и 2 совмещены вначале топика в фразе:
«Проделал N(^k) попыток копировать базу данных, удаляя файлы блокировок, is-corrupt и прочие. »
База полностью открыта — действительно можно много добавить возможностей, включая одновременный доступ посторонним ПО, резервное копирование или конвертацию в MySQL, где уже даже в phpMyAdmin появляется масса возможностей по разнообразной фильтрации истории.
Ну и, конечно, вопрос безопасности тут в полный рост.
Копировал. У меня бекап на другом винте, т.к. я переезжал на другой компьютер. Ну и есть несколько более старых архивов профиля, но полгода минимум потери данных — не лучший вариант.
Всё-таки хранить в текстовом формате не самый удобный способ, особенно когда база уже за 150Мб перевалила. Я сначала хотел конвертнуть всё в привычный мне MySQL, но потом обнаружил, что база битая и не всё так просто.
У меня нет цели восстановить всё до последнего сообщения. Мне прежде всего было важно вообще получить доступ к своей истории, т.к. некоторые диалоги мне важны чаще для восстановления хронологии событий, чем даже для их сути. Поэтому, конечно, настолько сильно закапываться в тонкости Sqlite смысла не был о. Я вообще рад, что получилось малой кровью (хотя это заняло несколько часов) всё вернуть. Но в целом, я согласен с тем фактом, что разработчик базы данных первым же делом должен заботиться об инструментах низкоуровневого восстановления. И уж, тем более, я удивлён — почему за много лет существования Skype там до сих пор нет инструмента автоматического резервного копирования (не говоря уж о таком простом способе быстрого восстановления БД).
К вышесказанному я бы добавил, что мы проводили внутренний сравнительный анализ множества мессенджеров или близких к ним технологий — Joram MQ, HornetQ (JBoss), ActiveMQ (Apollo, JMS), Qpid, Kestrell, ZeroMQ и прочих.
И в результате всё-равно выбрали именно Rabbit. Причин тому несколько, но среди ключевых — уникальная модель управления очередями. Консьюмер сам может указать серверу очереди и типы сообщений, которые ему нужны. Это на практике — очень эффективный инструмент. Выкладывать детальное сравнение нет возможности — оно не доведено до качества хорошей статьи, но в целом, сочетание скорости, удобства, стабильности (миллионы сообщений держит), настраивоемости, визуального управления и очень удобной модели работы с очередями — даёт много очков именно этому решению.
Но если стоите перед выбором — посмотрите HornetMQ. По тестам скорости, например, он давал лучшие результаты.
Я вот даже не юрист, но: Youtube & vk уже внесли в реестр запрещенных сайтов? Нет? Тогда требования каких законов нарушил провайдер? Никаких? Так тогда зачем заблокирован ресурс? На основании некого размытого письма перепуганного чиновника? Запоминайте провайдеров и отказывайтесь от их услуг — нет более действенного инструмента для прочистки мозгов, чем потеря прибыли.
Другой соцсетью она не пользуется, а внутренняя регистрация для человека, который на свой email раз в полгода заглядывает — устаревшая процедура. Кроме того, если в дальнейшем ваш сервис сможет сам постить результат на стенку соцсети — я бы хотел видеть это в той сети, где общаюсь с друзьями. А FB для меня — сервис обмена новостями с коллегами.
, ожидаемое значение всегда должно идти первым параметром в __call(). А условие — вторым параметром. Поэтому «больше-меньше», как кто-то комментировал к первой статье, похоже на йода-код. Просто нужно учитывать.
Тем не менее, люди хотят ознакомиться с более качественным подходом. Я не использую Yii, но как раз в данный момент работаю над аналогичной задачей в более широком спектре использования. От вашей публикации я ожидал как минимум демонстрации нескольких типов данных и более-менее готового решения, которое чему-то учит. Всё-таки данный ресурс — не личный дневник с заметками на полях.
Не говоря уже о том, что ваш код угробит значение '123456789876546548786546875468'.
Ну это просто несерьёзный подход. Вы публикуете статью «Приведение к типам», а в результате демонстрируете довольно сомнительное приведение к int и ничего более.
1. Есть рабочая база полугодовой давности.
2. Есть свежая копия профиля с предыдущей системы с побившейся базой.
Ваши пункты 1 и 2 совмещены вначале топика в фразе:
«Проделал N(^k) попыток копировать базу данных, удаляя файлы блокировок, is-corrupt и прочие. »
Ссылки в топике приведены:
habrahabr.ru/post/160315/
habrahabr.ru/post/158545/
База полностью открыта — действительно можно много добавить возможностей, включая одновременный доступ посторонним ПО, резервное копирование или конвертацию в MySQL, где уже даже в phpMyAdmin появляется масса возможностей по разнообразной фильтрации истории.
Ну и, конечно, вопрос безопасности тут в полный рост.
И в результате всё-равно выбрали именно Rabbit. Причин тому несколько, но среди ключевых — уникальная модель управления очередями. Консьюмер сам может указать серверу очереди и типы сообщений, которые ему нужны. Это на практике — очень эффективный инструмент. Выкладывать детальное сравнение нет возможности — оно не доведено до качества хорошей статьи, но в целом, сочетание скорости, удобства, стабильности (миллионы сообщений держит), настраивоемости, визуального управления и очень удобной модели работы с очередями — даёт много очков именно этому решению.
Но если стоите перед выбором — посмотрите HornetMQ. По тестам скорости, например, он давал лучшие результаты.
Это неинтуитивно. На массив? На пустой массив? На строку с двумя скобками?
, ожидаемое значение всегда должно идти первым параметром в __call(). А условие — вторым параметром. Поэтому «больше-меньше», как кто-то комментировал к первой статье, похоже на йода-код. Просто нужно учитывать.
Не говоря уже о том, что ваш код угробит значение '123456789876546548786546875468'.