Поэтому, когда изменяются данные в какой-то транзакции, мы создаём в memcache для конкурирующих потоков для нашего объекта ещё один ключ, наличие которого означает, что кеш этого объекта пока невалиден, и за данными объекта надо сходить в БД
Поясните пожалуйста, что Вы делаете, когда несколько процессов изменяют один объект. Одному удастся создать дополнительный ключ в кеше о невалидности основного ключа, а остальные ждут и периодически проверяют не исчез ли дополнительный ключ? И зачем этот ключ, если в БД то же самое что и в кеше пока транзакция незакоммичена?
Мечтаю об энджине для MySQL сбрасывающем кеш при коммите.
Зачем удалять если можно не удалять :) Технически ветки ничем не отличаются от тегов, лишние телодвижения по созданию тега, удалению ветки только усложнят и без того не простой процесс.
А баш-гит-комплитеру всё равно: он ищет и в ветках и в тегах.
$ time b --contains de88e382df3041d43f2aabca9e68a3aee8d1a2d3
PLATFORM-4227_pause_in_edit
real 0m1.996s
Очевидно что эта команда роется только в локальных ветках, которых вовсе не 2000 штук, а не более 10. Возможно имелось ввиду git branch -a…
Странная область применения, собирать данные для выдачи в пхпшные массивы, потом из них слепить xml объект, который отдать xslt процессору. Если используется такая замечательная технология как xslt, то зачем данные собирать в массивы — можно сразу строить xml-объект нужной структуры, разница будет не заметна :)
Расширение должно быть полезное для импорта, но упоминание xslt только сбивает с толку.
А ещё лучше бы сразу из пхпшной сериализации строило xml объектины, эдакий unserialize_to_xml :)
Это называется великий треугольник — производство, равно как и производимый продукт, может обладать тремя характеристиками: быстрое, качественное, дешёвое. Но можно выбрать только любые два.
Безусловно diff с тремя точками покажет изменения по ветке, в оригинальном GitPHP этой возможности нет, вот мы и добавили один простой вызов.
Нас вполне устраивает вид unified диффа в браузере + наша подсветка изменений символов в строке. Каждый сотрудник использует удобную ему операционную систему и GitPHP работает везде одинаково и требует только браузер, также никто не запрещает использовать другие средства, такие как meld или встроеный в phpstorm diff viewer. Но это только просмотр, в нашей версии есть возможность тут же написать комментарии и по окончании ревью уведомить разработчика и возможно обновить статус задачи в баг-трекере.
GitPHP очень простой инструмент и делает не больше чем вызов программы git с нужными параметрами.
Необходимость оптимизации настала, очень тоскливо ждать загрузки страницы с бранчдиффом по 20+ секунд. Инструмент уже был встроен в GitPHP, мы его только улучшили и поделились с автором.
В дефолтном гите ревьювер может написать комментарии к ветке/коммиту/файлу/строке в файле?
Что должен сделать инспектор, чтобы гит, поменял статус в баг трекере из SUBMITTED в ACCEPTED?
$STDOUT это просто перменная, можете назвать её иначе, как вам нравится
STDOUT это файловый дескриптор, который обычно открыт при запуске программы, запись в него приводит к отображению записанного на терминале, и также как и любой другой файловый дескриптор его можно закрыть функцией fclose, и если после этого открыть любой файл, то новый дескриптор будет иметь значение 1 и echo будет писать уже в него, потому что echo это по сути системный вызов write(1, ...)
На самом деле интересует реальный опыт используемого вами метода IPC.
По моему опыту мне хватило proc_open для задачи взаимодействия одного мастер процесса и десяти дочерних, все функции для этого есть в стандратном экстеншене:
$ php --re standard | grep -E 'fwrite|fgets|stream_select|proc_open'
Function [ <internal:standard> function proc_open ] {
Function [ <internal:standard> function fgets ] {
Function [ <internal:standard> function fwrite ] {
Function [ <internal:standard> function stream_select ] {
С кодировкой проблем не испытываю, бинарные данные также передаются, windows не использую, до блокировок дело не дошло, хотя через пайп 10 дочерних процессов шлют мегабайты данных.
С файлами проблема в том, что пишущий процесс должен закрыть файл, чтобы читащий мог нормально читать данные, чтобы не нужно было отслеживать последнюю прочитанную позицию, кажется как-то так.
Хороший обзор, хотелось бы примеров каждого из пунктов, буду ждать ещё статью :)
Почему это popen извращение? Сам popen это конечно же только односторонний IPC, но есть более продвинутый вариант proc_open. Благодаря которому получается unix-way взаимодействие между процессами через пайп.
Обе эти функции находятся в «экстеншене» core PHP, а это значит, что не нужно дополнительно собирать модули так, как это требуется для тех же pcntl и sockets, не говоря уже про кастомное расширение pthreads.
Про поиск ответили выше, а комментарии под фото собственно к этому фото и относятся(как многие к одному), а значит принадлежат владельцу фото, хоть и автор коммента не владелец.
Получается пользователь, его фоты, и комментарии к ним на одном шарде.
Гораздо интереснее ситуация когда пользователь А подписался на коменты к фотке/альбому пользователя Б и пользователь В добавил коммент. Или что то же самое А отметил Б на фотке В :)
[^\s]+ эквивалентно \S+
Поясните пожалуйста, что Вы делаете, когда несколько процессов изменяют один объект. Одному удастся создать дополнительный ключ в кеше о невалидности основного ключа, а остальные ждут и периодически проверяют не исчез ли дополнительный ключ? И зачем этот ключ, если в БД то же самое что и в кеше пока транзакция незакоммичена?
Мечтаю об энджине для MySQL сбрасывающем кеш при коммите.
Например можно описать требуемые отличия от стандарта по умолчанию
github.com/eelf/phpcf/commit/76c8c7205f4c316cb9f557ea960c8ed15a3a1eba#diff-d41d8cd98f00b204e9800998ecf8427e
Работает так
$ ~/phpcf/phpcf --style=compact apply classes/Db.php
или так
$ ~/phpcf/phpcf --style=minified apply classes/Db.php
А баш-гит-комплитеру всё равно: он ищет и в ветках и в тегах.
$ time b --contains de88e382df3041d43f2aabca9e68a3aee8d1a2d3 PLATFORM-4227_pause_in_edit real 0m1.996sОчевидно что эта команда роется только в локальных ветках, которых вовсе не 2000 штук, а не более 10. Возможно имелось ввиду git branch -a…
Расширение должно быть полезное для импорта, но упоминание xslt только сбивает с толку.
А ещё лучше бы сразу из пхпшной сериализации строило xml объектины, эдакий unserialize_to_xml :)
Нас вполне устраивает вид unified диффа в браузере + наша подсветка изменений символов в строке. Каждый сотрудник использует удобную ему операционную систему и GitPHP работает везде одинаково и требует только браузер, также никто не запрещает использовать другие средства, такие как meld или встроеный в phpstorm diff viewer. Но это только просмотр, в нашей версии есть возможность тут же написать комментарии и по окончании ревью уведомить разработчика и возможно обновить статус задачи в баг-трекере.
GitPHP очень простой инструмент и делает не больше чем вызов программы git с нужными параметрами.
Необходимость оптимизации настала, очень тоскливо ждать загрузки страницы с бранчдиффом по 20+ секунд. Инструмент уже был встроен в GitPHP, мы его только улучшили и поделились с автором.
Что должен сделать инспектор, чтобы гит, поменял статус в баг трекере из SUBMITTED в ACCEPTED?
STDOUT это файловый дескриптор, который обычно открыт при запуске программы, запись в него приводит к отображению записанного на терминале, и также как и любой другой файловый дескриптор его можно закрыть функцией fclose, и если после этого открыть любой файл, то новый дескриптор будет иметь значение 1 и echo будет писать уже в него, потому что echo это по сути системный вызов write(1, ...)
По моему опыту мне хватило proc_open для задачи взаимодействия одного мастер процесса и десяти дочерних, все функции для этого есть в стандратном экстеншене:
С кодировкой проблем не испытываю, бинарные данные также передаются, windows не использую, до блокировок дело не дошло, хотя через пайп 10 дочерних процессов шлют мегабайты данных.
С файлами проблема в том, что пишущий процесс должен закрыть файл, чтобы читащий мог нормально читать данные, чтобы не нужно было отслеживать последнюю прочитанную позицию, кажется как-то так.
Почему это popen извращение? Сам popen это конечно же только односторонний IPC, но есть более продвинутый вариант proc_open. Благодаря которому получается unix-way взаимодействие между процессами через пайп.
Обе эти функции находятся в «экстеншене» core PHP, а это значит, что не нужно дополнительно собирать модули так, как это требуется для тех же pcntl и sockets, не говоря уже про кастомное расширение pthreads.
Получается пользователь, его фоты, и комментарии к ним на одном шарде.
Гораздо интереснее ситуация когда пользователь А подписался на коменты к фотке/альбому пользователя Б и пользователь В добавил коммент. Или что то же самое А отметил Б на фотке В :)
{
«докопался»: true, «xml гаƒƒно»: true
}