ну и я бы для уменьшения латэнси логстэши на серваке держал с кодом который в него пишет

На серверах с приложением агент логстеша, остальное вместе с эластиком и кибаной на отдельном серваке

Логи напрямую в него не шлем чтобы иметь их всегда просто в виде файла

а зачем?

ну мол... удобнее ж в кибане логи сразу смотреть, или типа что бы задержку невилировать (в кибане они все ж с каким-то лагом)?

Там логи такие что их терять нельзя, ничему не доверяю так как нескольким копиям файлов на диске в разных дц

Всегда можно смигрировать на другой инструмент визуализации просто загнав файлы по новой

ребята, кто-то работал с либой https://github.com/tymondesigns/jwt-auth Вопрос по поводу того, как делать refresh токена. Я так понял, когда я использую $jwtGuard->refresh(), чтобы обновить токен, он как раз и проверяет refresh_ttl время?

привет, несколько дурной вопрос. Как мне для бд сгенерить уникальное числовое значение?

для столбца

новой записи

неужели гугл ничего не говорит по этому поводу?

привет, несколько дурной вопрос. Как мне для бд сгенерить уникальное числовое значение?

где сгенерить, на стороне БД или приложения?

привет, несколько дурной вопрос. Как мне для бд сгенерить уникальное числовое значение?

завист от бд. в нормальных есть секвенсы

либо рандом + uniq индекс + цикл

где сгенерить, на стороне БД или приложения?

на стороне приложения. У меня такая приблуда: https://pastebin.com/Rbtr5DXh но часто падает что уже есть такое значение

на стороне приложения. У меня такая приблуда: https://pastebin.com/Rbtr5DXh но часто падает что уже есть такое значение

юзай uuid

завист от бд. в нормальных есть секвенсы

mysql

или microtime + random

просто прикол в том что время от времени ошибка падает

просто прикол в том что время от времени ошибка падает

ну так рандом, что ты хотел

логично, что на вашей выборке время от времени происходит коллизия

ну так я же проверяю существует ли код

ну ты ж не лочишь)

видимо

лочу

ну короч разбирайся, вариантов тебе накидали

ибо ты ни ошибку не предоставил, ни вообще каких-либо деталей

Duplicate entry '2449' for key 'ivr_codes_code_unique' )

Duplicate entry '2449' for key 'ivr_codes_code_unique' )

еще раз - значит не лочишь

что именно?

может у него myisam, а он думает, что лочит? Я хз как это там в мускуле работает =\

inno

к примеру, есть код - 8947, смотрю по бд - а он есть, сделан 01.08 числа

Integrity constraint violation: 1062 Duplicate entry '8947' for key 'ivr_codes_code_unique' (SQL: insert into ivr_codes (code, entry_id, entry_type, ref_id, updated_at, created_at) values (8947, 31753, model, , 2018-08-10 12:19:36, 2018-08-10 12:19:36)

а сегодня ошибка

ладно))

есть 1 подозрение, спасибо)

а не

транзакции?

Я по мотивам вчерашнего обсуждания возвращения из контроллера не респонса сделал простенький бандл — https://github.com/igorkamyshev/ResponderBundle Как считаете, имеет ли право на существование такая штука?

Integrity constraint violation: 1062 Duplicate entry '8947' for key 'ivr_codes_code_unique' (SQL: insert into ivr_codes (code, entry_id, entry_type, ref_id, updated_at, created_at) values (8947, 31753, model, , 2018-08-10 12:19:36, 2018-08-10 12:19:36)

лови эту ошибку и повторяй

Я по мотивам вчерашнего обсуждания возвращения из контроллера не респонса сделал простенький бандл — https://github.com/igorkamyshev/ResponderBundle Как считаете, имеет ли право на существование такая штука?

да, вполне

да, вполне

Спасибо!

Igor A. Kamyshev (0) увеличил репутацию Sergey Protko (3)

Спасибо!

но тока если допилить, там сча чет как-то не оч

но задумка да, вполне себе

А что нужно допилить?

ну конкретно оно не хэндлит ситуацию что у тебя уже респонс вернулся. хотя в целом... хз может и норм

короч попробуй че)

То есть "вернулся"?

чуть что весь этот бандл имплементится одним файликом и пароч строчек yaml

Кто работает с прод и дев веткой - как решаете вопрос накатки хотфикстов идущих сразу в прод на дев ветку?

чуть что весь этот бандл имплементится одним файликом и пароч строчек yaml

Не понял. Каким образом?

Кто работает с прод и дев веткой - как решаете вопрос накатки хотфикстов идущих сразу в прод на дев ветку?

типо обычный git flow

да, и те у кого нету git flow

Кто работает с прод и дев веткой - как решаете вопрос накатки хотфикстов идущих сразу в прод на дев ветку?

Черипики. Сначала фиксим в мастере и потом черипики в релиз ветку

научите меня в trunk based development ?

руками?

научите меня в trunk based development ?

https://trunkbaseddevelopment.com - тут все есть

https://trunkbaseddevelopment.com - тут все есть

я пробовал пару раз

как то у меня не слишком хорошо получается)

руками?

Нет, ногами. Конечно руками

как то у меня не слишком хорошо получается)

Ну вот расскажешь что не получается тогда поговорим

не уместная шутка, к слову… руками совершенно не интересно, потом ловить кто забыл это сделать

не уместная шутка, к слову… руками совершенно не интересно, потом ловить кто забыл это сделать

вопервых это легко отслеживается, а во вторых - как ты определяешь что должно идти в релиз а что нет? Ну мол, вот как на уровне коммитов (предположим там есть ссылка на ишус в трекере) будешь это трекать?

лэйблы в ишусах?

ERROR: S client not available

пометки в релизы?

у нас непрерываня интеграция

у нас тоже

как это влияет на вопрос выше?

все попадает в транк

на пуш в прод ставится тег и деплой

это не про интеграцию тогда а про доставку

точнее нет

это вообще не очем

ни про CI и ни про CD

с CD у тебя транк на прод льется

с CI у тебя все изменения сначала в транк идут

если мне надо пофиксить баг - я сначала фикшу его в мастере а потом коммит с фиксом черепикается в релиз ветку. Это можно автоматизировать если у тебя нормально организован процесс трекинга всего в ишус трекере и все коммиты отмечаются номерами задачи

а дальше - пуш в ветку и деплой, или надо в слэке команду написать - это все не про CI/CD

CI в дев ветку, готовое в прод ветку

короч я ссылку на то как работаю скинул - trunk based dev

дальше я не оч понимаю твои про "руками" "не интересно" и "у меня CI"

потому что связи я тут никакой не вижу

руками черепикать не интересно, хочтеся делать это на пуше или на деплое

но черипик или мерж - оно не спасет от конфликтов по идее

руками черепикать не интересно, хочтеся делать это на пуше или на деплое

У тебя две ветки и один комит, можно черипик автоматизировать но тут все зависит от того как ты трекать должен коммит попадать в релиз ветку и в какую (у тебя она одна, тебе проще)

но черипик или мерж - оно не спасет от конфликтов по идее

Черепик спасет ибо в релиз только из масткра изменения попадают

Хотя опять же git слишком тупой чтобы не косячить

меня проблема конфликта волнует, если автоматизировать

А потому лучше руками

И стараться не делать много багов что бы не было желания автоматизировать)

ай, это другая песня… у 7-летнего монолита написанного джуниорами не может быть мало багов… даже если сейчас квалификация общая много выше

Так забавно чёт слушать за конфликты при мержах, черепиках ?. Если не тянуть задачи и не делать вливания по 100500 строк никогда их не бывает или бывают, но минимальны

меня проблема конфликта волнует, если автоматизировать

конфликтов не будет, но семантические конфликты возможны (например в мастере переименовали модуль, и ты в багфиксе создал новый файл, и гит это уже не разрулит)

Неужели у когото такая боль от конфликтов?

Так забавно чёт слушать за конфликты при мержах, черепиках ?. Если не тянуть задачи и не делать вливания по 100500 строк никогда их не бывает или бывают, но минимальны

что за глупость, достаточно, что бы задача затронула то же место, что и хотфикс

Так забавно чёт слушать за конфликты при мержах, черепиках ?. Если не тянуть задачи и не делать вливания по 100500 строк никогда их не бывает или бывают, но минимальны

так забавно что люди думают что конфликты бывают только когда 100500 строк кода)