DT
я просто подумал если наследовать от не абстрактной модели
то у двух моделей будет один PK
то у двух моделей будет один PK
Size: a a a
2020 July 09
DT
те не будет пересечения id
DP
Тогда почему бы не сделать два FK поля, task_id и personal_task_id ?
Я тоже сразу об этом подумал, фронт отказался что-либо менять....
RS
я просто подумал если наследовать от не абстрактной модели
то у двух моделей будет один PK
то у двух моделей будет один PK
Сейчас это две разные модели у человека, ты предлагаешь смерджить :)
Это тоже вариант, но менее популярный обычно
Это тоже вариант, но менее популярный обычно
S
Сейчас это две разные модели у человека, ты предлагаешь смерджить :)
Это тоже вариант, но менее популярный обычно
Это тоже вариант, но менее популярный обычно
Ибо уже конфликты есть
NC
Я тоже сразу об этом подумал, фронт отказался что-либо менять....
так возвращай ему с тем же ключем
DT
о нем просто мало кто знает
RS
Я тоже сразу об этом подумал, фронт отказался что-либо менять....
Причем тут фронт?
Как это скажется на фронте? И как в таком случае фронт готов работать с возможной ошибкой сейчас?
Как это скажется на фронте? И как в таком случае фронт готов работать с возможной ошибкой сейчас?
DP
Nikolay Cherniy
так возвращай ему с тем же ключем
Вернуть id не проблема, проблема понять, при создании, к какой модели отностится id
DP
Если уж делать 2 fk поля
B
Наверное плохо объяснил
Есть 3 модели
У
Ну и в контроллерах ищется по id эти таски. Проблема в том, что таска должна быть одна, а в некоторых случаях возвращаются 2
Есть 3 модели
TaskPersonalTaskMessageУ
Message есть поле task:int, куда записывается id одной из модели Task или PersonalTaskНу и в контроллерах ищется по id эти таски. Проблема в том, что таска должна быть одна, а в некоторых случаях возвращаются 2
А если добавить ContentType? И тогда можно будет бесконечно масштабировать
RS
То есть иметь корявую архитектуру бекенда с теоретическим боттлнеком при запросах в бд ок, лишь бы фронт спал спокойно? Я бы обсудил это
EM
Звучит странно, да
S
То есть иметь корявую архитектуру бекенда с теоретическим боттлнеком при запросах в бд ок, лишь бы фронт спал спокойно? Я бы обсудил это
Фронту оно не сдалось ведь по идее?
DT
ну кстати да, GenericForeignKey для этого сделаны
но мне они не нравятся
но мне они не нравятся
RS
Shodmon
Фронту оно не сдалось ведь по идее?
Ну да, просто когда бекенд будет валяться или тормозить, пусть фронт будет готов, хаха
DP
А если добавить ContentType? И тогда можно будет бесконечно масштабировать
Спасибо за идею
DP
Ну да, просто когда бекенд будет валяться или тормозить, пусть фронт будет готов, хаха
Меня тоже это бесит
B
Тогда почему бы не сделать два FK поля, task_id и personal_task_id ?
такое себе. Загонишь себя в ловушку таким подходом.