Может быть лучше вообще убрать из дампа Аа и аА, а оставить только маленькими и капсом? Сразу так не скажешь, но вполне возможно, что вы и правы. Просто я когда это писал, руководствовался тем, что нам вообще какбы неважен регистр, поэтому и вставил все вариации. Ну И МоЖНо ПРиДумАть ПрИМер, когда анализатор, как мне кажется, обломается, если убрать варианты аА.
Вполне возможно, что у нас с вами просто сильно различаются проекты и процессы, поэтому наша методика не подходит вам, а ваша — нам. Конечно же, методика, описанная в этом топике не является единственной и самой лучшей, просто для наших проектов и процессов разработки она подходит наиболее хорошо, а поэтому, я думаю, подойдет и большинству команд, имеющих похожие на наши процессы. Не всем, конечно.
Простейший пример: Петя переименовывет табличку users_tokens в user_tokens. Для этого он переименовывает ее в БД и переименовывет в каком-то методе is_authorized(). Это к примеру.
Что произойдет, когда работа ведется на общем сервере БД? Петя переименовал табличку, но еще не закоммитил измененный метод is_authorized(). У всех остальных разработчиков сайт поломался. Они кричат «кто сломал БД?». Петя — «я, сейчас закоммичу код». Все ждут Петю, Петя коммитит, все обновляются, все хорошо. Удобно? Мне кажется, не очень. А если Петя работает в бранче, это часть какой-то большой фичи, и не хотелось бы до полного тестирования сливать ее с транком? Нужно отдельно об этом думать.
Что произойдет, если команда работает с миграциями? Петя добавил миграцию с переименованием таблички, изменил код. Когда он закоммитит эти изменения (или смержит с транком, если работает в бранче отдельном), остальные после апдейта получат измененный метод is_authorized() и дельту с изменением имени таблички. Накатят апдейт своей локальной БД и продолжат работать.
Это, как показывает моя практика — самая частая задача при совместной разработке. Конечно, есть более сложные моменты, когда так все гладко не будет. Но это как конфликты в мержах (SVN) — они бывают всегда, и их нужно разруливать аккуратно руками.
Если все будут работать на одной БД и ее одновременно править — начнутся проблемы. Конечно, если править БД имеет право только один разработчик, то все хорошо. Но один программист, добавляя свой функционал, может сломать БД остальных. Ну и плюс возможно параллельно ведутся разные ветки проекта — на каждую ветку отдельную БД нужно делать. Потом я захочу сделать тестовую ветку, на которой потестить, например, разные ключи, попробовать что-то денормализовать, [вписать свое] — опять нужно создавать еще одну БД.
Не согласен, что дельты с номерами это более упрощенный вид. Как раз отказ от номеров дельт дает очень много преимуществ в виде возможности независимо менять структуру БД и добавлять новые дельты в ветках и не думать об их нумерации. Это очень удобно.
Очень хороший пример, спасибо. На самом деле мы сталкиваемся с такой проблемой время от времени. Обычно я чтобы переключиться на транк использую дополнительную БД. На продакшене и тестовых серверах такого не произойдет — только на машинках разработчиков, а это уже намного проще обрабатывать кому как удобно. Мое мнение — это небольшая цена за существенное упрощение всего процесса.
Мне кажется, что эта задача не связана с версионированием структуры БД. При любом подходе тут возникнут одни и те же вопросы.
Как вариант решения — INSERT INTO tbl2 ([поля кроме id]) (SELECT [поля кроме id] FROM tbl1), когда наш суррогатный ID в tbl2 просто сделается новый для записей из tbl1.
Я так понимаю, девелоперы дропают всю базу, накатывают себе Base.sql, а потом измененный Changes.sql при изменении структуры другим членом команды? Интересный подход, спасибо.
Если можете, расскажите, по каким причинам такой упрощенный подход не работает на других проектах? Ну или предположим, мой подход, почему он не будет работать на каких-нибудь проектах? Может быть нас ждут в ближайшем времени проблемы, а мы их просто пока не замечаем
Каскадную файловую систему, наверное, все-таки из Kohana взяли, а не из ZF?
По классам/файлам действительно очень напоминает Кохану. Тот же bootstrap.php, те же фактически действия в index.php — создание основных констант путей, вызов bootstrap.php. Тот же base.php в ядре.
спасибо за ссылку на хак. Как-нибудь надо посмотреть, как она работать будет на невалидном HTML.
Но. Все-таки задачи парсинга HTML не ограничиваются парсингом идельных UTF-8 страничек, поэтому с вами не могу согласиться, что все зависит от задачи. Как я сам в свое время пришел к такому выводу: никогда не было проблем с парсингом — до того момента, как не сделали одну систему, в которую заказчик вводит грубо говоря URL и XPath — и получает в базе у себя результат парсинга. Таких ужасов насмотрелись, когда сайтов много и разных появилось… И на KOI8-R, и с битым UTF-8, и без meta… Чего только не сделают вебмастера. Я к чему это — сделать более или менее работающий парсер, который все это учитывает (браузеры же учитывают как-то) — цены бы ему не было.
Перечитал еще раз статью. Увидел «страницы должны быть в UTF-8».
Cтраницы не обязаны быть в UTF-8. Насколько я помню свои опыты с DOMDocument — ваш код будет работать и на других кодировках входного HTML с условиями, описанными в моем комментарии выше. DOMDocument, насколько я помню (поправьте меня, если я не прав) сам узнает кодировку из тега meta и преобразует уже к UTF-8 все на выходе.
Помойму, самая большая проблема в парсинге HTML — это получить нормальное читабельное дерево DOM. Как уже с ним работать — оберток написано масса. Вариант, предложенный автором не самый худший это точно — за это автору респект, конечно.
Столкнулся с такой проблемой при обработке через DOMDocument кириллических страниц и страниц в UTF-8. По идее в этом парсере тоже должны быть такие проблемы — буду признателен, если кто-нибудь проверит. У меня, к сожалению, не под рукой PHP сейчас, чтобы самому проверить.
1) кириллический текст например в title до meta с указанием кодировки — вся кириллица превращается в htmlentities. Если она была в UTF-8, то обратно ее уже нельзя будет вернуть через html_entity_decode()
2) отсутствие тега meta с указанием кодировки — то же самое, что и п.1
3) битый UTF-8 — например, если кто-то сделал у себя на сайте substr($title, 250), чтобы сильно длинный тайтл не показывать ) — решается через iconv('UTF-8', 'UTF-8//IGNORE', $html);
4) на невалидном HTML ведет себя сильно отлично от большинства браузеров. Например, если встретит td внутри div — все дерево DOM будет перекошено ого-го как. Выдернуть из него почти ничего не реально.
Собственно, алгоритм у меня такой был перез загрузкой в DOMDocument:
1) находим meta content-type. Если не нашли — определяем кодировку сами и генерируем нужный meta content-type.
2) вставляем его в самое начало head.
3) если работаем с UTF-8 — удаляем битые символы.
После этих нехитрых операций большинство страниц парсилось более или менее хорошо. За исключением, конечно, сильно битого HTML. Но это уже нетривиальные задачи, которые решаются в браузерах — в libxml такое нереально решить.
Была идея выдернуть парсер HTML из WebKit, например, но я подумал, что это уже слишком жестко для такой задачи )
Решение с n-граммами на php есть по ссылке в топике (в разделе «поиск по хабру» вторая ссылка). Действительно на мой взгляд очень хорошее решение проблемы. Просто ИМХО несколько избыточно — для детекта языка в самый раз, а кодировки попроще можно детектить.
Простейший пример: Петя переименовывет табличку users_tokens в user_tokens. Для этого он переименовывает ее в БД и переименовывет в каком-то методе is_authorized(). Это к примеру.
Что произойдет, когда работа ведется на общем сервере БД? Петя переименовал табличку, но еще не закоммитил измененный метод is_authorized(). У всех остальных разработчиков сайт поломался. Они кричат «кто сломал БД?». Петя — «я, сейчас закоммичу код». Все ждут Петю, Петя коммитит, все обновляются, все хорошо. Удобно? Мне кажется, не очень. А если Петя работает в бранче, это часть какой-то большой фичи, и не хотелось бы до полного тестирования сливать ее с транком? Нужно отдельно об этом думать.
Что произойдет, если команда работает с миграциями? Петя добавил миграцию с переименованием таблички, изменил код. Когда он закоммитит эти изменения (или смержит с транком, если работает в бранче отдельном), остальные после апдейта получат измененный метод is_authorized() и дельту с изменением имени таблички. Накатят апдейт своей локальной БД и продолжат работать.
Это, как показывает моя практика — самая частая задача при совместной разработке. Конечно, есть более сложные моменты, когда так все гладко не будет. Но это как конфликты в мержах (SVN) — они бывают всегда, и их нужно разруливать аккуратно руками.
Как вариант решения — INSERT INTO tbl2 ([поля кроме id]) (SELECT [поля кроме id] FROM tbl1), когда наш суррогатный ID в tbl2 просто сделается новый для записей из tbl1.
Если можете, расскажите, по каким причинам такой упрощенный подход не работает на других проектах? Ну или предположим, мой подход, почему он не будет работать на каких-нибудь проектах? Может быть нас ждут в ближайшем времени проблемы, а мы их просто пока не замечаем
По классам/файлам действительно очень напоминает Кохану. Тот же bootstrap.php, те же фактически действия в index.php — создание основных констант путей, вызов bootstrap.php. Тот же base.php в ядре.
Но. Все-таки задачи парсинга HTML не ограничиваются парсингом идельных UTF-8 страничек, поэтому с вами не могу согласиться, что все зависит от задачи. Как я сам в свое время пришел к такому выводу: никогда не было проблем с парсингом — до того момента, как не сделали одну систему, в которую заказчик вводит грубо говоря URL и XPath — и получает в базе у себя результат парсинга. Таких ужасов насмотрелись, когда сайтов много и разных появилось… И на KOI8-R, и с битым UTF-8, и без meta… Чего только не сделают вебмастера. Я к чему это — сделать более или менее работающий парсер, который все это учитывает (браузеры же учитывают как-то) — цены бы ему не было.
Cтраницы не обязаны быть в UTF-8. Насколько я помню свои опыты с DOMDocument — ваш код будет работать и на других кодировках входного HTML с условиями, описанными в моем комментарии выше. DOMDocument, насколько я помню (поправьте меня, если я не прав) сам узнает кодировку из тега meta и преобразует уже к UTF-8 все на выходе.
Помойму, самая большая проблема в парсинге HTML — это получить нормальное читабельное дерево DOM. Как уже с ним работать — оберток написано масса. Вариант, предложенный автором не самый худший это точно — за это автору респект, конечно.
Столкнулся с такой проблемой при обработке через DOMDocument кириллических страниц и страниц в UTF-8. По идее в этом парсере тоже должны быть такие проблемы — буду признателен, если кто-нибудь проверит. У меня, к сожалению, не под рукой PHP сейчас, чтобы самому проверить.
1) кириллический текст например в title до meta с указанием кодировки — вся кириллица превращается в htmlentities. Если она была в UTF-8, то обратно ее уже нельзя будет вернуть через html_entity_decode()
2) отсутствие тега meta с указанием кодировки — то же самое, что и п.1
3) битый UTF-8 — например, если кто-то сделал у себя на сайте substr($title, 250), чтобы сильно длинный тайтл не показывать ) — решается через iconv('UTF-8', 'UTF-8//IGNORE', $html);
4) на невалидном HTML ведет себя сильно отлично от большинства браузеров. Например, если встретит td внутри div — все дерево DOM будет перекошено ого-го как. Выдернуть из него почти ничего не реально.
Собственно, алгоритм у меня такой был перез загрузкой в DOMDocument:
1) находим meta content-type. Если не нашли — определяем кодировку сами и генерируем нужный meta content-type.
2) вставляем его в самое начало head.
3) если работаем с UTF-8 — удаляем битые символы.
После этих нехитрых операций большинство страниц парсилось более или менее хорошо. За исключением, конечно, сильно битого HTML. Но это уже нетривиальные задачи, которые решаются в браузерах — в libxml такое нереально решить.
Была идея выдернуть парсер HTML из WebKit, например, но я подумал, что это уже слишком жестко для такой задачи )