M
Size: a a a
2020 September 21
К
Да, я уже переделывал с double на простые integer - и пустое значение оценивал как нективно, 0 - как активно-безнаценки, а 1+ как активно с наценкой. Это превращает 150 полей в 100. Но недостаточно для того, чтобы 100 перестало быть 100.
VS
идеальный кейс - это таки перейти на свои сущности, может даже в плоскую таблицу закинуть
VS
а из ноды - референсить
AP
В пору field builder делать)
AP
идеальный кейс - это таки перейти на свои сущности, может даже в плоскую таблицу закинуть
А cck (какой-то из) умел добавлять столбцы)
К
пошёл читать про плоские таблицы, спасибо.
Про свои сущности - Вы имеете в виду вынести список вкусов в отдельную ноду, а потом референсом крепить её к профилю?
Думал об этом, но боюсь, что это не уменьшит объем данных в респонсе и он всё равно будет крашится в 500 ошибку
Про свои сущности - Вы имеете в виду вынести список вкусов в отдельную ноду, а потом референсом крепить её к профилю?
Думал об этом, но боюсь, что это не уменьшит объем данных в респонсе и он всё равно будет крашится в 500 ошибку
К
почему то дело в количестве
M
Да, я уже переделывал с double на простые integer - и пустое значение оценивал как нективно, 0 - как активно-безнаценки, а 1+ как активно с наценкой. Это превращает 150 полей в 100. Но недостаточно для того, чтобы 100 перестало быть 100.
Витя правильно советует, у тебя же фильтр и идет допустим по цвету, во вьюсе выводить надо только цвет, а наценку можно референсом цеплять, а в админке выводить уже как computed, чтобы админу удобно было заполнять
VS
Витя правильно советует, у тебя же фильтр и идет допустим по цвету, во вьюсе выводить надо только цвет, а наценку можно референсом цеплять, а в админке выводить уже как computed, чтобы админу удобно было заполнять
ну нет, я не так советовал
VS
но любой вариант лучше чем текущий
К
Витя правильно советует, у тебя же фильтр и идет допустим по цвету, во вьюсе выводить надо только цвет, а наценку можно референсом цеплять, а в админке выводить уже как computed, чтобы админу удобно было заполнять
ну так прикрепить к каждому цвету референс на наценку... это помоему объем ответа не уменьшит... или я чтото не так понимаю?
M
ну так прикрепить к каждому цвету референс на наценку... это помоему объем ответа не уменьшит... или я чтото не так понимаю?
а это смотря как реализовывать)
К
Подскажите, как реализовать правильно.
Есть план сделать все вкусы - одним полем с группой чекбоксов.
Но как тогда к ним правильно зареференсить наценку, если они все будут одним полем, а не отдельными со своими идентификаторами?
ПРивязываться к лейблам чекбоксов - так себе вариант... переименование или уточнение в будущем может натворить проблем
Есть план сделать все вкусы - одним полем с группой чекбоксов.
Но как тогда к ним правильно зареференсить наценку, если они все будут одним полем, а не отдельными со своими идентификаторами?
ПРивязываться к лейблам чекбоксов - так себе вариант... переименование или уточнение в будущем может натворить проблем
VS
во всяком случае, можно начать с постоянных вкусов, которые почти не изменились за последние лет так тыщу
К
у каждого вида вкуса свой id, в плоской таблице делаешь связь id вкуса|id профиля которому принадлежит вкус, там же булин поле да/нет и если да, то в интеджер поле наценку
пока не знаю как работать с плоскими таблицами, гуглю, читаю. Попробую если разберусь, спасибо за наводку
К
заранее уточню на всякий случай. По этой схеме не придётся делать 50 полей для каждого из вкусов в самом нодтайпе?
И предполагаю, что сделать открытые фильтры во вьюз тогда станет определённого рода проблемой, так?
И предполагаю, что сделать открытые фильтры во вьюз тогда станет определённого рода проблемой, так?
АК
поставь профиль умами, там должны быть вкусы