Да? Ну ладно. Не застал.

Всем привет, никто не может подсказать, как мне вытащить из массива данные и присвоить их к переменной, или смержить с существующим массивом в переменной? тоесть у нас есть $TO_TPL = array ( 'test' = 0 ) array ( 'departFrom' => 22 ) $TO_TPL['departFrom'] //22 $TO_TPL['test'] //0

как грамотно это смержить? через array_merge ?

$TO_TPL = array_merge($TO_TPL, array('departFrom' => 22));

спасибо) именно так и сделал

о, работорговцы пожаловали

Народ, а кто чем пользуется для экспорта в excel ? В проект на Symfony4 нужно что нить простое и топорное.

Народ, а кто чем пользуется для экспорта в excel ? В проект на Symfony4 нужно что нить простое и топорное.

phpexel

phpexel

Он сейчас PHPSpreadsheet. Сложноват синтаксис, что-нить попроще бы. Типа, вот есть https://github.com/MewesK/TwigSpreadsheetBundle, использующая с интеграции Twig. Вот что нить на подобие бы.

да ладно. там элементарно всё

примеров полно

В общем, по phpoffice знаю. Ищу альтернативы и надстройки для Symfony

лучше phpoffice по-моему нет ничего, всякие легкие надстройки рискованы своей сыростью.

Всем привет, столкнулся с проблемой при работе с PhpWord Мне надо в сущетсвующий файл, к таблице добавить строку, решения на просторах интернета не нашел Кто-то сталкивался с такой проблемой ?

А есть какая-то более короткая запись выражения (кроме как без фигурных скобок)? if (!isset($data['field'])) { throw new \Exception('Bla bla bla'); }

зависит от версии php

А есть какая-то более короткая запись выражения (кроме как без фигурных скобок)? if (!isset($data['field'])) { throw new \Exception('Bla bla bla'); }

$data['field'] = (!isset($data['field'])?$data['field']:throw new \Exeption('bla bla bla')); Или не прокатит? ?

А есть какая-то более короткая запись выражения (кроме как без фигурных скобок)? if (!isset($data['field'])) { throw new \Exception('Bla bla bla'); }

validate(['field' => 'required'], $data)

$data['field'] = (!isset($data['field'])?$data['field']:throw new \Exeption('bla bla bla')); Или не прокатит? ?

Тогда можно было бы еще короче isset($data['field']) && throw new \Exception('bla bla bla');, но нет - облом

validate(['field' => 'required'], $data)

спасибо конечно ))) интересует именно "нативная" реализация

Ну тогда вариант Adel ?‍♂

спасибо конечно ))) интересует именно "нативная" реализация

ну а кто мешает реализовать самому? :)

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

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

так не надо нагружать. это просто функция validate и набор правил валидации

DTO остается той же

в целом да

ну я не в шутку это предложил. если у тебя часто такие вещи попадаются, то весьма правильно это выделить в отдельный класс(функцию) а если не часто, то зачем пытаться сократить?

А есть какая-то более короткая запись выражения (кроме как без фигурных скобок)? if (!isset($data['field'])) { throw new \Exception('Bla bla bla'); }

не нужно отказываться от фигурных скобок, это редкостный говнокод можно конечно сократить используя http://php.net/manual/en/language.operators.comparison.php#language.operators.comparison.coalesce

не нужно отказываться от фигурных скобок, это редкостный говнокод можно конечно сократить используя http://php.net/manual/en/language.operators.comparison.php#language.operators.comparison.coalesce

Согласен, не собираюсь отказываться ? Поэтому и спросил. Конструкция вида $data['field'] = $data['field'] ?? throw new \Exception('bla') невалидная по-моему

Согласен, не собираюсь отказываться ? Поэтому и спросил. Конструкция вида $data['field'] = $data['field'] ?? throw new \Exception('bla') невалидная по-моему

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

это точно ?

Пхаха зачёт

Ребята, есть необходимость хранить версии сущностей в бд. Есть продукт, у него много данных - категории, статусы, цена, опции и т.д. Все данные разбросаны по таблицам с соответствующими связями. Какие подходы в решении данной задачи посоветуете?

пиши историю в монго

Ты имеешь ввиду серелизовать объект и кидать в монго?

как угодно, лишь бы понятно

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

event sourcing ?

Не знаю масштаба, может глупо будет, у нас просто дифы лежат. Текущее состояние плюс история изменений. Хранится история прав и профиля, там немного.

event sourcing ?

спасибо, сейчсас ознакомлюсь

спасибо, сейчсас ознакомлюсь

он пошутил

хотя и правильный совет дал :)))

но это как пушкой по воробьям

он пошутил

=) откуда ж мне знать, если не сталкивался с этой технологией.

под версией ты имеешь ввиду версию документа или версию структуры документа?

под версией ты имеешь ввиду версию документа или версию структуры документа?

под версией я подразумеваю как изменялась сущность. Смотри, мы создали продукт с свойствами title='продукт1', price=555. Допустим, для него ставим версию 1. Потом мы заапдейтили этот продукт и изменили его цену на 777. Теперь у продукта версия 2. Вопрос сам заключается в том, как это правильно разруливать. Где хранить версии продуктов, в тех же таблицах с указанием версии и с указанием id родителя?

ERROR: S client not available

пиши историю в монго

ты с ней работал хоть раз? ;) сколько раз терял данные?

Я в свое время реализовывал очень простой вариант версионирования и он в принципе работал нормально. 1. Тебе нужно научиться получать хэш от документа по тем полям, изменение которых ты будешь считать за изменение версии документа. Этот хэш ты генерируешь на уровне приложения. 2. Тебе нужна вторая таблица, которая будет хранить историю изменения сущности. Например, у тебя есть таблица table_entity, создай вторую таблицу table_enity_history с набором полей из table_entity, но с добавлением доп. поля - documentHash и, возможно доп. набором а-ля createdOn, modifiedById и т.д. 3. У таблицы table_entity_history поле documentHash нужно будет сделать уникальным, чтобы оно являлось частью составного PRIMARY_KEY Далее на уровне приложения когда происходит изменение документа ты считаешь его хэш и транзакционно делаешь вставку/обновление в обе таблицы, причем во вторую делаешь INSERT IGNORE. Если тебе нужно добавить доп. поле, то ты добавляешь его в обе таблицы. Вот и вся любовь. Достаточно просто. Но нифига не гибко.

ты с ней работал хоть раз? ;) сколько раз терял данные?

ни разу

люблю простые советы, бери foo или bar и будет всё

Ребята, есть необходимость хранить версии сущностей в бд. Есть продукт, у него много данных - категории, статусы, цена, опции и т.д. Все данные разбросаны по таблицам с соответствующими связями. Какие подходы в решении данной задачи посоветуете?

какая конечная цель подобного хранения?

какая конечная цель подобного хранения?

Цена на продукт может меняться. Допустим, человек заходит на сайт и видит, что цена на продукт 10 долларов, это акционная цена и человеку такая низкая цена нравится. Он делает заказ по этой цене и ожидает, что заплатит 10 долла в конечном итоге. Но в проекте при оформлении ордера нельзя указывать цену продукта, как это обычно бывает (вот такие условности проекта). И получается, что мы указываем в ордере id продукта, его количество. Но завтра цена на продукт поменялась на 50 долларов. И когда посмотрим на ордер - то получается, что человек купил продукт по цене уже в 50 долла.

появилась необходимость хранить версии продуктов. Т.е. в ордере указывать, что человек купил товар с такой-то версией, а для этой версии уже была определённая цена

у тебя 2 разных товара, с разными ценами. версии не решат кучи проблем с ценообразованием

Цена на продукт может меняться. Допустим, человек заходит на сайт и видит, что цена на продукт 10 долларов, это акционная цена и человеку такая низкая цена нравится. Он делает заказ по этой цене и ожидает, что заплатит 10 долла в конечном итоге. Но в проекте при оформлении ордера нельзя указывать цену продукта, как это обычно бывает (вот такие условности проекта). И получается, что мы указываем в ордере id продукта, его количество. Но завтра цена на продукт поменялась на 50 долларов. И когда посмотрим на ордер - то получается, что человек купил продукт по цене уже в 50 долла.

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

Добрый день. Только знакомлюсь с сокетами, выбрал библиотеку workerman. Решил сделать чатик: личные сообщения, сообщения для группы. Думаю сделать следующим образом: На фронте создавать json, отправлять на сервер, а на сервере уже уго разбирать (для группы это сообщение или приватное). Подскажите, это правильный подход?

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

насчёт "дурацкого проекта" согласен. Но условия задачи таковы, что нельзя прокидывать цену в ордере. Плюс, появляется возможность смотреть как менялся товар в каком-то промежутке

насчёт "дурацкого проекта" согласен. Но условия задачи таковы, что нельзя прокидывать цену в ордере. Плюс, появляется возможность смотреть как менялся товар в каком-то промежутке

А что мешает завести отдельную табличку для истории цен? ID товара, цена, дата изменения.

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

А что мешает завести отдельную табличку для истории цен? ID товара, цена, дата изменения.

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

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

Ну значит делается вертикальная таблица и в неё пишется история изменений. Запись реализуется в родительском классе для всех сущностей в районе метода save

как ты будешь в эту таблицу класть many-to-many? У товара есть категории

как ты будешь в эту таблицу класть many-to-many? У товара есть категории

это все легко сделать если подумать, у тебя с этим проблемы?

это все легко сделать если подумать, у тебя с этим проблемы?

он предлагает делать 1 таблицу с историей изменений. Т.е. many-to-many класть в 1 колонку? Это ж бред

в любом случае это же изменения, собирать все данные в json

Большинство вещей которые сложно делать на самом деле просто лень делать.

в любом случае это же изменения, собирать все данные в json

как потом по ним выборки делать?

ребят. а какой регуляркой весь текст вытащить html страницы?

есть какая-то универсальная