Антон позвал Бориса чтобы мы его убедили )

как вариант )

он просто кидал лог хистори, вот я открыт ко всему новому, если это имеет смысл, пока я его не уловил =)

если вам оно не надо, то и не делайте

никто вас убеждать не собирается )

что именно не надо? )

ну просо у каждого метода должны быть + и - , очевидных плюсов пока не вижу, а минусов кучу

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

зависит от того, как выглядит операция для пользователя

можете еще посмотреть Marco Pivetta - Doctrine ORM Good Practices and Tricks

гляну, спс

зависит от того, как выглядит операция для пользователя

грубо в 2х словах , запрос падает в контроллер, в контроллере вызывается сервис , сервисе идут валидации, через репу дергается ентити - у ентити проставляются поля

что значит через репу дергается энтити О.О

em->getRepository('blablabla')->find(:id)

и это ваша инфраструктура, если у пользователя есть действие обновить профиль и он там обновляет все, то тогда метод update, которй принимает Profile, если у него отдельные формы изменения, то changeBilling(BillingInfo ...

em->getRepository('blablabla')->find(:id)

ну вы просто нашли сущность же

дальше что?

чем лучше изменение стейта в сущности, чем в сервисе?

тем, что если эта информация может приходить еще с мобилки

и чтобы не было дублирования вы дерните тот же метод модели

или эта операция происходит при действии с другой сущностью

я дерну тот же сервис , почему нет

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

что если для мобилки мне условно надо проверить 3, поля я для не мобилки 3

ну вот, у вас разные методы

дял не мобилки 5

ну получится , что в модели лежат прмиерно схожие методы , которые похожи на процентов 30-40

чем это лучше

условно registerFromMobile registerFromWeb

ну получится , что в модели лежат прмиерно схожие методы , которые похожи на процентов 30-40

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

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

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

вот вот

я не делаю круды

и никому не советую)

там по сути 80% ентити это моедли с полями 3-10 полей , без какой-то супер логики

я не делаю круды

совет из разряда , не пишите на пхп, а переходите на яву) но спасибо в любом случае

вам просто и доктрина с симфони это оверхед жесткий

совсем непонятно зачем

на фоне которого методы в сущности выглядят нетак заметно)

и никому не советую)

если все послушают твой совет, то все встанет и все... конец)))

наоборот, круды бизнесу не нужны

круды уже сделаны и автоматизированы

бизнесу нужна автоматизация\визуализация

часто, но это мое мнение

наоборот, круды бизнесу не нужны

Нам(работодателю=) ) это помогает экономить на железе)

экономить на железе? вконтакте что ли?)

экономить на железе? вконтакте что ли?)

не-не, маштаб поменьше)

какие есть варианты для заливки файла с одного сервера на другой? из тех что знаю - апдлоад через апи - маунт подсистемы через nfs - по ssh - ftp сервер

- rsync

smb

- smb

)

- webdav

- rsync

rsync это нужно локально еще копию держать, а нужно только в 1 конец перебросить

smb

+

ок. тогда такой вопрос. кто что использует в проектах?)

ну если тебе надо передать куда-то, то локальная копия у тебя уже есть

ftp-smb

Alexander тащи

у нас в проде nfs. с "сервера на сервер" все по нфс бегает. на самом деле все живет на паре серверов, а они уже примонтированы там где надо. но это говно. в ближайшем будущем планируем ceph

у нас тоже через маунт

те кто на S3 сидят вроде только через апи гоняют

а если просто надо слить 1-2 файлика - scp, или shell-соединение в mc =)

ну s3 у меня через s3fs примонтирован

в общем-то работает нормально, проблем не замечал

ERROR: S client not available

те кто на S3 сидят вроде только через апи гоняют

+ по апи делаем... через gaufrette

народ, а делать токен доступа одновременно и идентефикатором - норм идея?

@F01134H ты про JWT?

Посоны, небольшой вопрос, кто сможет меня пропатчить по рекурретным нейронкам? Что бы понимать всю ситуацию - в ML я дальше K нейборст ни в зуб ногой >_< Ну там за плату, по скайпику как-нибудь

ютуб не зашел что ли?

@F01134H ты про JWT?

У меня не JWT)

просто токен от апи

стоит ли юзать его как идентефикатор определенного юзера

ютуб не зашел что ли?

на ютубчике теория, а хрен поймёшь теорию, без понимания того, что она значит

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

стоит ли юзать его как идентефикатор определенного юзера

есди это id сессии, и ты мапишь его 1-1 к юзер айди, то почему нет

restful же отрицает любое хранение информации, не?

+ у меня нет аутентефикации, пока даж не задумывался о ней

любой запрос содержит token=[blablabla]

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

типо есть бд |id|username|token 1 user 555 и какой запрос будет вернее: POST /user/1/message?message=test&token=555 или POST /user/message?message=test&token=555

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

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

да

restful же отрицает любое хранение информации, не?

эт где такое написано??

эт где такое написано??

В вики черным по белому указано, что один из столпов рест апи - https://en.wikipedia.org/wiki/Stateless_protocol

Да и не надо париться с сохранением сессий, все просто)

Коняш а ты как считаешь? По вопросу выше

@atnartur там ниже полистай

про архитектуру будет

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

Над тобой не стоят с палкой и не просят сделать именно те

Так

Я сонный, не буду влезать в холивар. Но на первый взгляд stateless rest звучит странно

Возможно там немножко иной смысл

Не, именно такой)