да хоть как

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

как часто?

Не самое рациональное использование 1Ски))

точно в штуках нужно отвечать, а не думаю бла бла

Важнее было бы посмотреть пример выгрузки. По нему можно понять, подхватится ли с битриксом без допила или нет. Если нет, то ясно будет одно: - тяп ляп и в продакшн не выйдет. нужен будет разраб, ну или самому немного приложить силенок. Иначе: готовое решение и в путь с песней. Считаю это первостепенным вопросом в данной задаче)

руками пусть набивают тогда :)

ну наймут чувака он им по 15р товар забьет

А потом окажется, что там еще 7-я 1С

Кстати офигенная идея

я знаю одно кафе которое так делает каждый день

только не на сайт, а в инста... но сути это не меняет

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

в общем symfony наше все, остальное мрак и грусть

не, симфони уже давно не можно, сейчас прикалываются по фреймворк агностик ;)

кому как а для меня symfony самое то

и ADR паттерн ага

главное, что там три буквы

если я хочу, например, $user->addRole(Role::someone()), где Role::someone() создает объект Role с нужным ID... и потом юзера сохранить, а на роль стоит cascade ... что делать, что бы нарушений уникального ключа не было? В репозитории брать роли, делать селекты и проверять?... про доктрину вопрос

где ты видишь нарушение uk?

это доктриновские заморочки

что значит "на роль стоит cascade "?

она будет пытаться сохранять все связанные модели... а так как объект Role не доставался из базы - она не знает, что он есть и пытается сделать insert в роли

Можно, конечно, отключить каскад (тогда доктрина при сохранении пользователя не будет сохранять роли, даже если они "новые"), и добавлять новые роли миграцией... как бы хотел упростить немного, создал именнованный конструктор в модели Role, если в базе такого нет - оно туда сохранилось.

нет

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

да, роли принято добавляь миграциями

Доктрина сама любит хендлить внешние ключи

И вообще лезть во все аспекты

да внешние ключи никуда и не деваются... каскад - это просто... ну типа есть у тебя две модели связанные и тебе надо $post = new Post(); $post->addTopic(new Topic()); - если каскад выключен, то тебе нужно вызвать сохранение топика, а потом - сохранение поста. Если в конфиге по этой связи каскад - то сохраняем только пост, а доктрина сама посмотрит связи, какие там объекты, и сохранит их

да, надо вызывать сохранение топика, потом сохранение поста

не надо полагаться на то, что Доктрина прочтет наши мысли

иногда это может сработать, а иногда выстрелит в ногу

это уже логика, превращает модели в active record

не знаю, я полагаюсь на документацию, а не на шаманство, оно работает и работает именно так, как нужно

иногда это может сработать, а иногда выстрелит в ногу

Кеке это прям мои ощущения от доктрины ?

Но на простых случаях все работает отлично

дык в AR все так и прописывается, по документации - связи сущностей, типы связей, только это не считается хорошим дизайном

А доктрина еще и таблицы генерит по этим описаниям

это немного другое

И ругается если описание не соответствует тому что реально есть в схеме бд

как бы причем тут AR я не понял, ну ок

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

AR - это data mapper + business logic

к логике приложения описанное отношение не имеет, это логика сохранения в базу

логика сохранения в базу - это как insert генерить :)

а когда его выполнять - это логика приложения

когда его выполнять да, возможно... на этом и заказчивается, на "сохрани мне все это в базу", а как, в каком порядке и т.п. - это persistance layer

в принципе, да

довольно сложно отделить "все это" от логики приложения

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

все-равно в будущем sql запросов править придется

бб

если я хочу, например, $user->addRole(Role::someone()), где Role::someone() создает объект Role с нужным ID... и потом юзера сохранить, а на роль стоит cascade ... что делать, что бы нарушений уникального ключа не было? В репозитории брать роли, делать селекты и проверять?... про доктрину вопрос

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

модно хейтить доктрину не разобравшись в ней

все-равно в будущем sql запросов править придется

dbsimple все еще используешь наверное?

нет, я запросы руками пишу, а что?

Доктрина странная

И ей часто нужно доказывать кейсами что действительно надо разрешить это сделать тебе

Всего лишь инструмент с весьма ограниченными возможностями

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

любой ORM добавляет определенные ограничения

в большинстве случаев я предпочитаю простой query builder, а ORM писать руками

Доктрина странная

нормальная она, просто ты хочешь странных вещей :)

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

наоборот её, тебя избавляют от всей мороки с данными и написанием SQL запросов руками в 80% случаев

нормальная она, просто ты хочешь странных вещей :)

Это называется разработка

А не странные вещи это CRUD шлепать

Еще доктрина не умеет работать нормально со схемами в постгресе

Нельзя ей сказать "смотри в схемы, a,b,c а в схемы d e f не смотри"