=) но вопрос остался тем же, зачем локальный Dockerfile если мы фактически вручную вносим изминения в родительский образ? Зачем тогда вообще что то собирать? Сделали docker pull чего нам надо, и юзаем
Андрей. спасибо за такие подробные ответы, но я хотел бы уточнить.
Вы тестируете образом «covex/php7.1-fpm:1.0», а на продакшене образ от этого файла который наследуется от «covex/php7.1-fpm:1.0».
Если вы будете менять образ для прода, вы ведь в этот же файл планируете вносить изминения, а не в базовый образ? Если так, то получается два разных образа.
На сколько я знаю, кеширование папок делается вот так
cache:
paths:
- vendor/
А каким образом это происходит у вас? ведь наполненый кеш композера и заполненая папка vendors это все таки разные вещи. И для исполнения скриптов нужно чтоб были фалы в vendors, а не в кеше композера.
Но это не боевой контейнер, а «covex/php7.1-fpm:1.0», вы ведь когда будете изменять php docker image (тут) образы могут быть разные. Вы тестируете не тем образом что будет в продакшене
и возможно, такой pipeline возможно тогда будет лучше
build — создаем контейнеры и пушим в Registry deps — используем созданные контейнеры из Registry test — используем созданные контейнеры из Registry
Кстати, ведь для тестов вероятно нужны будут зависимости, но так как это другая джоба, то зависимостей не этапе теста нет. Тут наверное нужно объеденить deps и test в одну джобу?
мне кажется, что лучше на job-ах deps:php-composer и test:phpunit лучше использовать реальный php контейнер. Ведь если мы добавим в composer.json зависимость, которому будет необходим какой то экстеншн то тесты на зависимость уже не пройдут. Та же ситуация с phpunit, но тут еще и настройки php добавляются.
Скажите, используете ли вы проверку кода (CodeSniffer)? Как вы считаете, уместно ли проверять код именно тут. Ведь на сколько я понимаю, если код не прошел проверку, то его просто вообще нельзя запушить на сервер.
Спасибо за вопрос. Он меня натолкнул на размышление. Вообще я не гуру, и даже не спец SQL. Просто данное решение работает очень быстро. Что мне собственно и нужно. Хотелось бы все знать, но увы. Человеческий ресурс.
Вопрос к знатокам.
Делаю запрос, поле filters, которое как помним INTEGER[].
SELECT * FROM products WHERE filters @> ARRAY[7267]
Index Scan using products_idx on public.products (cost=0.14..8.16 rows=1 width=68)
Output: id, title, filters
Index Cond: (products.filters @> '{7267}'::integer[])
Индекс, GIN (gin__int_ops)
Bitmap Heap Scan on public.products (cost=8.01..12.02 rows=1 width=68)
Output: id, title, filters
Recheck Cond: (products.filters @> '{7267}'::integer[])
-> Bitmap Index Scan on products_idx (cost=0.00..8.01 rows=1 width=0)
Index Cond: (products.filters @> '{7267}'::integer[])
Если взять в пример, хотлайн или фотос, то там фильтр это запись в бд. Это может быть range или нет, это вообще не важно. Фильтр для товара, на уровне базы, это просто метка. На проекте где я реализовал такой поход, есть дополнительные обработчики, которые определяют в какой фильтр должен входить товар и автоматически назначают его.
Я не спорю в целом. А конкретно в данном случае, фильтры это записи в таблице. т.е. у них есть ID:INTEGER.
Поиск по инту быстрее чем по строке, пусть и полнотекстовым поиском со всеми умными индексами.
а что до «какие значения фильтров есть у найденных товаров?», ну тут мы тоже имеем айдишки на выходе.
Вы тестируете образом «covex/php7.1-fpm:1.0», а на продакшене образ от этого файла который наследуется от «covex/php7.1-fpm:1.0».
Если вы будете менять образ для прода, вы ведь в этот же файл планируете вносить изминения, а не в базовый образ? Если так, то получается два разных образа.
А каким образом это происходит у вас? ведь наполненый кеш композера и заполненая папка vendors это все таки разные вещи. И для исполнения скриптов нужно чтоб были фалы в vendors, а не в кеше композера.
Вы описали так джоб, где композер инсталирует зависимости
Но это не боевой контейнер, а «covex/php7.1-fpm:1.0», вы ведь когда будете изменять php docker image (тут) образы могут быть разные. Вы тестируете не тем образом что будет в продакшене
build — создаем контейнеры и пушим в Registry
deps — используем созданные контейнеры из Registry
test — используем созданные контейнеры из Registry
Кстати, ведь для тестов вероятно нужны будут зависимости, но так как это другая джоба, то зависимостей не этапе теста нет. Тут наверное нужно объеденить deps и test в одну джобу?
Скажите, используете ли вы проверку кода (CodeSniffer)? Как вы считаете, уместно ли проверять код именно тут. Ведь на сколько я понимаю, если код не прошел проверку, то его просто вообще нельзя запушить на сервер.
Вопрос к знатокам.
Делаю запрос, поле filters, которое как помним INTEGER[].
Если индекса, нет
Индекс, GIST (gist__int_ops)
Индекс, GIN (gin__int_ops)
Не тот ли это битмап, о котором вы спрашиваете?
Вообще если говорить о фильтре для каталога магазина, то эти ползунки менее привлекательны, т.к. много движений делать нужно.
Если магазин токовый, то набор фильтров для определенной категории, тщательно продумывается.
Для пользователя гораздо легче просто кликнуть чем думать о том что указать. Тем более если он не в теме.
Поиск по инту быстрее чем по строке, пусть и полнотекстовым поиском со всеми умными индексами.
а что до «какие значения фильтров есть у найденных товаров?», ну тут мы тоже имеем айдишки на выходе.