это да

это все не по существу конечно. у меня к сожалению нет такого опыта.

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

Попробуй поднять тестовую конфигурацию и пофлуди запросами

это все не по существу конечно. у меня к сожалению нет такого опыта.

Тоже

ну насколько много? есть 1к транзакций в секунду хотя бы?

в пиковые моменты до 8к доходим

неплохо

постгрес?

постгрес?

мускуль

неплохо

это только 2 дня в неделю

в остальном прыгает от 500 до 1200

Попробуй поднять тестовую конфигурацию и пофлуди запросами

это конечно верно, но хотяться услышать мнение именно уже от людей, кто реально в боевом режиме юзать подобную реплику

Вроде в этих ваших интернетах ничего не нашёл по этому поводу)

ну тут нужно в целом про мастер-мастер репликации читать, yii тут уже просто клиент

граблей полюбому масса

ну тут нужно в целом про мастер-мастер репликации читать, yii тут уже просто клиент

дело в том, что сейчас это работает на yii1 через костыль, проект мигруется на yii2 - поэтому возник данный вопрос

ну как мигрируетесь, пишите статейку на хабр)

ну как мигрируетесь, пишите статейку на хабр)

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

дело в том, что сейчас это работает на yii1 через костыль, проект мигруется на yii2 - поэтому возник данный вопрос

чтож за сервис у вас такой мощный)

ребят, хрен знает поднималась ли эта тема или нет, но вот если коротко: для относительно шаблонных приложений с возможным большим количеством кастомных расширений этот способ организации подойдет?) https://habrahabr.ru/post/329286/

выглядит сексуально, никакого переписывания стандартных конфигов, мердж конфигов из расширения в расширение, но... по сути, это вопрос копипастинга нескольких строчек конфига и ппц)

Как правильно хранить frontend часть со всеми npm gulp конфигами, css, картинками, файлами и прочим в месте с yii2?

Как правильно хранить frontend часть со всеми npm gulp конфигами, css, картинками, файлами и прочим в месте с yii2?

Хоронить? )

ребят, хрен знает поднималась ли эта тема или нет, но вот если коротко: для относительно шаблонных приложений с возможным большим количеством кастомных расширений этот способ организации подойдет?) https://habrahabr.ru/post/329286/

С первых строк, там какая-то проблема высосанная из пальца...

Yii это не cms

С первых строк, там какая-то проблема высосанная из пальца...

Но можно организовывать что-то на подобии кмс в таком ключе

Но можно организовывать что-то на подобии кмс в таком ключе

Это фреймворк. Делай все что тебе хочется, он лишь задаёт направление.

Это фреймворк. Делай все что тебе хочется, он лишь задаёт направление.

Фермворк?

Это фреймворк. Делай все что тебе хочется, он лишь задаёт направление.

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

Вопрос из разряда собака или кошка)

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

Все предельно просто

Стандартный конфиг - это сконфигурированный класс.

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

Если в классе что-то меняется несовместимое с прежней работой делается новая мажорная вверсия, копируется новый конфиг

Конфиги наследовать как-то странно. И выпускать мажорные версии из-за изменений в конфиге тоже. ПМСМ

Не ну тут как бы не вижу проблемы: если ты меняешь конфиг кардинально, то скорее всего ты и делал какие-то мажорные изменения в коде расширения

Конфиги наследовать как-то странно. И выпускать мажорные версии из-за изменений в конфиге тоже. ПМСМ

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

Но это только имхо

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

Можешь привести пример?

Оказывается asset-packajist написав в подобном стиле

Можешь привести пример?

Конкретный сложно, я сам пока в поисках кейсов за и против. Но видется это так: есть расширение стороннего разработчика, и ты используешь его каким либо образом в своем расширении. Получается как бы древо: проект - твое расширение - стороннее. Ты знаешь, что сторонее нужно допустим подключить в конфиге приложения не с дефолтными настройками, чтобы твое расширение могло использовать его. Ты делаешь в своем расширении конфиг с нужными настройками как своего, так и стороннего и мерджишь в конфиг приложения с помощью composer-config-asset

Если бы делать это без config-asset, то нужно либо переопределять настройки приложения в бутстрапе твоего компонента, либо копипастить настройки в конфиг

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

А подход - расширение без конфига не рассматривается?

Бесспорно, в идеале хоть вообще только класс указывай) но не всегда так бывает, особенно со сторонними расширениями с ненужными для тебя стандартными настройками

Мне просто нравится идея иерархии не только в пакетах, но и в их конфигурации

А мы про какой сейчас конфиг говорим? yii main.php или другой? :)

Main, конфиг приложения yii)

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

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

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

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

Это на самом деле уже частный случай.

Типа написали cms, к ней кучу своих пакетов. И под заказчика подключаешь.

Но как правило какое-то расширение тем и прекрасно, что оно дефолтно и нетронуто. Берешь интерфейс и лепишь.

А что делать если расширение обновилось и у него изменился конфиг? Опять мерджить?

Че-т пока не могу сообразить как без рук обойтись

Обновляешь через композер апдейт расширение и оно после генерации автозагрузчика смерджит новый конфиг. Если же ты переопределял какое нибудь свойство расширения в основном конфиге, а в новой версии его нет то тут уж без ошибки не обойтись

Но и в обычном случае без него бы не обошлось

Зато если не менять тот дефолтный конфиг, что дает расширение, а в новой версии он поменяется, то тогда даже чесаться не придется

А в обычном случае пришлось бы ручками перезаписать main.php)

Таким образом можно целые конфиги приложений с блекджеком и контроллерами выносить в пакеты, а потом рекваить в шаблон и переопределять в конфиге только самое нужное: настройки базы, добавить в controllerMap кастомные контроллеры и тд

на фронте каленьдарь скачай да расставляй как тебе надо

1 таблица календарь, в нем события записываются

2 таблица сами события

1 ко многим

чо тут сложного?

как ид события

ID | EVENT ID | DATE START | DATE END

как datetime указать и все

чо?

нет

таблица событий примерно event_id | parent_id | title | comment где parent_id родитель

т.е. 1 событие становится зависимо от другого

выбрав курс ыт подтянешь все другие события

заполнишь при помощи календаря на фронте

https://fullcalendar.io/ типа такого

не обязательно этот, их много

вон даже в 1 таблицу есть https://github.com/jamelbaz/FullCalendar-BS3-PHP-MySQL/blob/master/calendar.sql

привет ребят) вопрос такой, мне пришли миграции в виде sql файлов/ теперь придется вручную модели править.. как-нибудь можно упростить этот процесс?

привет ребят) вопрос такой, мне пришли миграции в виде sql файлов/ теперь придется вручную модели править.. как-нибудь можно упростить этот процесс?

нанять того, кто их будет править вручную?

миграции?)

почему не делать миграции сразу в формате пыхи?)