Не все разработчики идеальны, как и все люди, и, как и все мы, могут совершить ошибку, особенно в большом проекте. Если бы ошибок не было… Эх! Это было бы счастье! :)
Точнее, из логов комитов можно делать trac-ссылки на тикеты и другие комиты. И наоборот, из тикетов делать ссылки на комиты. Совсем полной автоматизации процесса там нет, имхо.
А еще лучше ввести шаблон лога, который бы стимулировал заполнять некоторое количество обязательных полей (номер тикета, и т.п.), а также писать само описание комита, ну и, поддерживаю, проверять это в момент комита ;)
Попробую возразить. Иногда как раз одна маленькая фича затрагивает большие куски кода (маленькой она казалась только на первый взгляд). Ну а разработчики имеют свойство болеть, уходить в отпуск, менять работу, а еще забывать то, что они сделали. Иногда для меня лог комита — единственное, что позволяет вспомнить, что же я сделал, если это было год или полтора назад ;)
Но это дело вкуса, конечно. Я не говорю, что надо описывать какие-то детальные изменения, но если, например, изменена логика работы метода, она должна быть описана, если метод добавлен, то должно быть написано его предназначение. Вряд ли будет интересно знать из лога его параметры и т.п., но зачем он нужен и что он делает — вот это главное, по-моему. И в чём была мотивация его создания.
А как после этого по логу ревизий оценить что случилось с файлом в каждой из ревизий? Я довольно часто сталкивался с такой задачей. Например, я вижу, что большой и сложный модуль (или группа модулей) начал давать сбои. Первая моя мысль — проглядеть комиты в него за последний месяц (если я знаю, что месяц назад всё было хорошо). При этом часто оказывается, что разработчик, работая над фичей XXX комитит изменения в модуль YYYY, который вроде бы к этой работе отношения не имеет (комитит намеренно или просто случайно). Грубо, решали проблему «съехавшей ссылки» а изменили модуль ORM, как по логу «Фикс съехавшей ссылки» понять, что случилось с ORM-подсистемой? А часто такой комит затрагивает несколько файлов, имея общий лог с общей фразой (что тоже зло, по-моему).
Вот мой пост про то, что этого маловато бывает. Это мой личный опыт, может кому-то это будет полезно. Сам как руководитель разработки заставляю уж как минимум ссылку на тикет и текст изменения давать в логе, но хочется и большего часто.
Да, именно так. Причем, возможно, эти 6 строчек спасли мне два часа отладки, когда через неделю я буду искать баг, который случайно привнёс этим комитом. Или спасёт кому-то еще часы работы, когда он будет искать в логе ревизий то или иное изменение этого файла.
Тут идёт впечатление из опыта работы. Да, это замедляет каждый комит, но ускоряет работу в целом.
Мой пост ни в коем случае не претендовал на полноту охвата вопроса, а просто поднимал проблему, которую многие (на моем личном опыте) совсем не понимают, считая наличие индекса панацеей от всех проблем.
То что касается моего ответа на предыдущий пост — да, может быть всё, что угодно, и это зависит не только от запроса/схемы базы данных, но и от данных таблицы, а они могут быть разными. Также влияет настройка оптимизатора и т.п. Тут нет четкой границы вида «100» записей и индекс начнет работать или наоборот. С другой стороный, очевидно, что в таблице из двух строк база данных никогда не будет использовать ни один индекс (это крайний случай).
В приведенном примере у БД нет шансов увидеть корреляцию между значениями двух полей таблицы. И, соответственно, план запроса будет строиться из общих соображений. Увидев селективность по каждому из индексов, общее количество строк в таблице и другие параметры, БД может:
Не знаю заранее, но было бы интересно, какова скорость полнотекстового поиска на Lucene, переписанном на PHP? Насколько отличается от реализаций на C/C++/Java?
У полнотекстового поиска какая-то часть работы уходит на ввод-вывод, это несомненно (и здесь язык реализации не играет существенной роли), но есть всё-таки операции и на процессоре, и их часть обычно существенна.
Насчет win32 - не знаю, не смотрел, да и мне не нужно.
Полей как таковых в смысле БД нет, но можно при индексации к документу добавить value: Xapian::Document::add_value, где ключом является число (не очень удобно, заводим константы в коде), а значением - произвольная строка. При поиске с помощью OP_VALUE_RANGE ищем по этим значением (писал об этом выше).
Насчет морфологии - есть stemming, то есть по сути изменение окончания слов по "образцу". См., например: Xapian::QueryParser::set_stemmer, http://xapian.org/docs/stemming.html
Одним из минусов Xapian я бы назвал не самую удобную документацию. Фактически источником информации являются статьи на сайте (несколько разрозненные), различные примеры в блогах, а также документация (Doxygen) по С++ API (родному) от Xapian.
Часто в PHP-варианте API Xapian надо поглядеть в PHP-код обертки, в C++ API, подумать, а потом написать очередной кусок кода. Зато когда всё уже написано, получается логично и хорошо ;)
Как использующий Xapian могу добавить, что его возможности поиска очень развиты, подход к самому поиску основан на математической модели Information Retrieval (http://www.xapian.org/docs/intro_ir.html). Есть возможность к каждому документу добавлять произвольный набор "value" (значений), по которым в том числе можно осуществлять поиск. Поиск по таким значениям не самый эффективный (лучше по обычным термам - словам документа), но с помощью value можно осуществить дополнительную фильтрацию результатов поиска.
Интеграция с PHP & Python (что мы сами пробовали) - без особых проблем, расширение на SWIG есть для обоих. Возможность поиска на одном сервере - пожалуйста, если надо делать распределенную систему (поисковый сервер и веб-морды клиенты) - есть вариант доступа к поисковой БД по TCP. В этом случае индексация идёт на поисковом сервере, обращения на чтения - со всех остальных серверов (в том числе "наживую", т.е. во время индексации (доиндексации)). Индексация выполняется через транзакции, т.е. можно обеспечить логическую целостность обновления индекса.
Для создании read-only кластера поисковых серверов индекс можно в момент, когда нет обращений к поиску, растащить хоть rsyncом по произвольному количеству read-only Xapian-слейвов.
Но это дело вкуса, конечно. Я не говорю, что надо описывать какие-то детальные изменения, но если, например, изменена логика работы метода, она должна быть описана, если метод добавлен, то должно быть написано его предназначение. Вряд ли будет интересно знать из лога его параметры и т.п., но зачем он нужен и что он делает — вот это главное, по-моему. И в чём была мотивация его создания.
Тут идёт впечатление из опыта работы. Да, это замедляет каждый комит, но ускоряет работу в целом.
То что касается моего ответа на предыдущий пост — да, может быть всё, что угодно, и это зависит не только от запроса/схемы базы данных, но и от данных таблицы, а они могут быть разными. Также влияет настройка оптимизатора и т.п. Тут нет четкой границы вида «100» записей и индекс начнет работать или наоборот. С другой стороный, очевидно, что в таблице из двух строк база данных никогда не будет использовать ни один индекс (это крайний случай).
У полнотекстового поиска какая-то часть работы уходит на ввод-вывод, это несомненно (и здесь язык реализации не играет существенной роли), но есть всё-таки операции и на процессоре, и их часть обычно существенна.
Если будете тестировать, напишите, интересно :)
Полей как таковых в смысле БД нет, но можно при индексации к документу добавить value: Xapian::Document::add_value, где ключом является число (не очень удобно, заводим константы в коде), а значением - произвольная строка. При поиске с помощью OP_VALUE_RANGE ищем по этим значением (писал об этом выше).
Насчет морфологии - есть stemming, то есть по сути изменение окончания слов по "образцу". См., например: Xapian::QueryParser::set_stemmer, http://xapian.org/docs/stemming.html
Часто в PHP-варианте API Xapian надо поглядеть в PHP-код обертки, в C++ API, подумать, а потом написать очередной кусок кода. Зато когда всё уже написано, получается логично и хорошо ;)
Интеграция с PHP & Python (что мы сами пробовали) - без особых проблем, расширение на SWIG есть для обоих. Возможность поиска на одном сервере - пожалуйста, если надо делать распределенную систему (поисковый сервер и веб-морды клиенты) - есть вариант доступа к поисковой БД по TCP. В этом случае индексация идёт на поисковом сервере, обращения на чтения - со всех остальных серверов (в том числе "наживую", т.е. во время индексации (доиндексации)). Индексация выполняется через транзакции, т.е. можно обеспечить логическую целостность обновления индекса.
Для создании read-only кластера поисковых серверов индекс можно в момент, когда нет обращений к поиску, растащить хоть rsyncом по произвольному количеству read-only Xapian-слейвов.