@perin

"Выжми из бизнеса всё", это про нашу бюрократию и налоги. А все эти книжки, так, ерунда маркетинговая )

Вау, кто-то заражается хорошими практиками :) продолжай, ты в правильном пути идёшь!

не понял твоей фразы

я этим практикам следовал еще с версии 5.0

я выше описал почему. потому что у меня в проекте сейчас базовый класс для всех моделей занимает 2800 строк и там такая пиздота внутри. хотя проект писали 2 синьйора как бы. пришлось просто слой моделей взять и выбросить

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

другая сторона медали: делать запросы к елке в контроллерах. Эта привычка побудит делать контроллеры по 2500к если проект будет расти. Технический долг начнет расти быстро

это как теория разбитых окон если кто слышал

я уже такое видел много раз. видел один контроллер в 4 тыс строк, где 6 case по 500 строк и еще куча всего ))))

я сам стараюсь представить модель как доменную модель. Это не только класс модели, но и все вспомогательные классы. богатая домменая модель как одно целое

не понял твоей фразы

Да я просто рад видеть тебя, тут в чате, судя по уровню вопросов, в основном, люди и пихают логику в контроллер и ёлку.

я сам стараюсь представить модель как доменную модель. Это не только класс модели, но и все вспомогательные классы. богатая домменая модель как одно целое

Aggregate root типа?

Да я просто рад видеть тебя, тут в чате, судя по уровню вопросов, в основном, люди и пихают логику в контроллер и ёлку.

я тут сам пытался агитировать делать по уму. это бесполезно походу

Вау, кто-то заражается хорошими практиками :) продолжай, ты в правильном пути идёшь!

Меня забрызгало чьим то чсв.

Aggregate root типа?

ну нет. DDD тяжело применить. Просто лайтовая версия

как то логически с точки зрения бизнеса сгруппировать. Например Order, OrderService, OrderRepository, etc. Может не совсем по всем практикам, но это гораздо легче поддерживать чем все яйца в кучу

Меня забрызгало чьим то чсв.

Таки показалось вам, сударь. Чем больше работаю и вникаю в суть программирования, тем больше понимаю, что я ещё только в начале пути.

Народ, в таблице со статусами есть статусы с company_id = 1

Я из компании пытаюсь таким образом получить статусы для компании 2

wgereHas погугли

Ага, сейчас, спасибо

странная связь какая то

Все таки похоже что это немного не то) Мне нужно из компании с ид 2, получить статусы компании с ид 1

при жадной загрузке например у тебя не будет $this->id вообще. будет null

Тобиш релейшен примерно такой "получаем статусы текушей компании и компании с ид 1"

Хмм, а как можно по нормальному реализовать получение каких-то дефолтных данных?

Например статусов в моем случае

Тобиш релейшен примерно такой "получаем статусы текушей компании и компании с ид 1"

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

Да, наверное

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

Да, я понял идею. Пожалуй так и сделаю сейчас

Спасибо большое

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

кстати минутка образования: кто знает термин мемоизация? а кто не знает загуглите и будете знать)

Кто подскажет почему в методе коллекции - трансформ , не применяются никакие операции хеширования.

Кто подскажет почему в методе коллекции - трансформ , не применяются никакие операции хеширования.

непонятно что имеется ввиду. мб покажи код

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

спасибо за ответ

непонятно что имеется ввиду. мб покажи код

Скрин выше

Скрин выше

всё дело в том что у тебя модели. и у моделей по дефолту id это праймари кей и по дефолту он автоинкрементен и соответс твенно он по дефолту имеет кастинг в int

всё дело в том что у тебя модели. и у моделей по дефолту id это праймари кей и по дефолту он автоинкрементен и соответс твенно он по дефолту имеет кастинг в int

Бррр, тоесть поменять на интеджер просто и все заведется?

Бррр, тоесть поменять на интеджер просто и все заведется?

что поменять на интеджер?

что поменять на интеджер?

Колонку в таблице не автоинкремент сделать а просто инт

Колонку в таблице не автоинкремент сделать а просто инт

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

https://github.com/laravel/framework/blob/5.6/src/Illuminate/Database/Eloquent/Concerns/HasAttributes.php#L856-L863 https://github.com/laravel/framework/blob/5.6/src/Illuminate/Database/Eloquent/Model.php#L1259-L1267 https://github.com/laravel/framework/blob/5.6/src/Illuminate/Database/Eloquent/Model.php#L62

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

Что именно прописать в модели что бы отменить это поведение

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

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

Только для вывода

В бд автоинкремент

ну можешь на лету сделать у моделей ->setIncrementing(false)

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

ну можешь на лету сделать у моделей ->setIncrementing(false)

Не у компа еще, попробую отпишусь! Спасибо!

а зачем вы юзаете AI ?

а зачем вы юзаете AI ?

Какой-то явной причины нет, а это плохая практика?

я думаю это стандартная штука типо id для внутреннего пользования а хеш для сокрытия id для внешнего

я думаю это стандартная штука типо id для внутреннего пользования а хеш для сокрытия id для внешнего

Именно

Какой-то явной причины нет, а это плохая практика?

ну по крайней мере, есть такое мнение :)

ну по крайней мере, есть такое мнение :)

а что ты ему предлогаешь вместо? uuid?

я не ориентируюсь сейчас на конкретный кейс и не советую, просто стало интересно первопричину ;)

я не ориентируюсь сейчас на конкретный кейс и не советую, просто стало интересно первопричину ;)

ну как бы а ты что юзаешь в качестве id? это дефолтное поведение

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

ну как бы а ты что юзаешь в качестве id? это дефолтное поведение

любой уникальный ключь

Доктрина впилена и тд

любой уникальный ключь

это какой?

user_id допустим

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

ERROR: S client not available

ты оперируешь на то, что AI дает твоим данным некую согласованность :)

user_id допустим

что такое user_id?

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

так а какой профит, я же и спрашиваю зачем вы используете AI

что такое user_id?

ты задал супер абстрактный вопрос без контекста, я тебе ответил на него)

у меня есть подозрение что ты как то по своему понимаешь AI

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

ты спросил какой, я привел пример

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

AI - auto increment или arificial intellect?

первое

потому что это удобно и под это многое что заточено

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

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

но ведь у реальных данных нет ключа)

потому что это удобно и под это многое что заточено

удобно в плане?)

но ведь у реальных данных нет ключа)

Тем и удобно что БД сама создает тебе этот ключ

без твоего участия

так а юз кейсы будут?

так а юз кейсы будут?

удаление, изменение модели

поиск

связи

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

ну это придирка к терминологии. да и метод называется обчно find)

Это мы понимаем, а люди могут подумать что реально поиск по не первичному ключу ?

А то добавят auto increment к текстам и будут считать что у них поиск по тексту работать теперь будет ?

коллеги. не флуда ради. подскажите почему ларка юзает activerecord в лице Eloquent, в то время как сам паттерн немножко нарушает принципы solid и симфони с версии 2 уже переползли на datamapper ?

Просто разные весовые категории: Yii - это массовый RAD фреймворк. Там важна простота и скорость. Ради этого можно забить на архитектуру. Он живёт почти вообще без SOLID и прочих штук. И там почти никто не знает про DIC, конструкторы, приватные поля, PSR и шаблонизаторы. Symfony и Zend - это, наоборот, самые навороченные энтерпрайз-решения для серьёзных проектов, где абсолютно всё сделано по SOLID и прочим принципам и лучшим архитектурным практикам. Laravel - промежуточный вариант, построенный на компонентах Symfony и своих с добавлением собственных упрощений. Там можно работать как в RAD-режиме с фасадами и CRUD-ами для простых проектов, так и как угодно заморачиваться для сложных. Поэтому в массовых Yii и Laravel в комплекте идёт простая ActiveRecord, а в специфичных уже какой-либо DataMapper. Но никто не мешает при желании подключить либо Doctrine в Laravel, либо Eloquent или Propel в Symfony.

да да AР такой плохой и не интерпрайзный, но почему то он и в ларе и в рельсах и в джанго

видимо для неосиляторов священного грааля в виде датамепера

да да AР такой плохой и не интерпрайзный, но почему то он и в ларе и в рельсах и в джанго

Ruby on Rails' emergence in the 2000s greatly influenced web app development, through innovative features such as seamless database table creations, migrations, and scaffolding of views to enable rapid application development. Ruby on Rails' influence on other web frameworks remains apparent today, with many frameworks in other languages borrowing its ideas, including Django in Python, Laravel in PHP, Phoenix in Elixir, and Sails.js in Node.js.

Ruby on Rails' emergence in the 2000s greatly influenced web app development, through innovative features such as seamless database table creations, migrations, and scaffolding of views to enable rapid application development. Ruby on Rails' influence on other web frameworks remains apparent today, with many frameworks in other languages borrowing its ideas, including Django in Python, Laravel in PHP, Phoenix in Elixir, and Sails.js in Node.js.

и? это типо в ларе и в джанго АР только потому что он в рельсах? слабый аргумент. и имхо влеяние рельсов на другие фреймы переоценивают

и? это типо в ларе и в джанго АР только потому что он в рельсах? слабый аргумент. и имхо влеяние рельсов на другие фреймы переоценивают

Нет. AR там потому, что всё Вами перечисленное - это RAD-фреймворки.

ок

да да AР такой плохой и не интерпрайзный, но почему то он и в ларе и в рельсах и в джанго

Так что в тысячах неэнтерпрайзных массовых простых проектов удобен простой неэнтерпрайзный AR. А в единицах энтерпрайзных специфических - энтерпрайзный сколь угодно кастомизируемый DM. Логично.