DT
что в GET ?
Size: a a a
2020 January 21
Z
ничего
Z
нашел где у меня затор стоит в методе гет
S
Трям! Вопрос про пермишны.
Мне надо добавить свои пермишены, я могу в Meta модели написать
permissions = [('codename', 'Название')]
Это круто, но что если у меня 90% таблиц через inspectdb сделаны, у них нет миграций как можно добавить к ним пермишны?
Создать для этого отдельную модель?
Пихать все в одну модель?
Есть другие варианты?
Мне надо добавить свои пермишены, я могу в Meta модели написать
permissions = [('codename', 'Название')]
Это круто, но что если у меня 90% таблиц через inspectdb сделаны, у них нет миграций как можно добавить к ним пермишны?
Создать для этого отдельную модель?
Пихать все в одну модель?
Есть другие варианты?
С
Трям! Вопрос про пермишны.
Мне надо добавить свои пермишены, я могу в Meta модели написать
permissions = [('codename', 'Название')]
Это круто, но что если у меня 90% таблиц через inspectdb сделаны, у них нет миграций как можно добавить к ним пермишны?
Создать для этого отдельную модель?
Пихать все в одну модель?
Есть другие варианты?
Мне надо добавить свои пермишены, я могу в Meta модели написать
permissions = [('codename', 'Название')]
Это круто, но что если у меня 90% таблиц через inspectdb сделаны, у них нет миграций как можно добавить к ним пермишны?
Создать для этого отдельную модель?
Пихать все в одну модель?
Есть другие варианты?
Создать к ним миграции?
S
Создать к ним миграции?
Хм.. а че так можно? миграции ради пермишенов. Это че мне вношу изменения в таблицу потом инстепкДБ а потом migration делать?
PZ
Есть кто не спит? Подскажите, почему pytest не проходит, хотя в postman все меняется
test - https://dpaste.org/pWdq
Ошибка WARNING django.request:log.py:228 Not Found: /api/v1/client_information/123456/
По сути это 404, но я по этому адресу делаю создание клиента
test - https://dpaste.org/pWdq
Ошибка WARNING django.request:log.py:228 Not Found: /api/v1/client_information/123456/
По сути это 404, но я по этому адресу делаю создание клиента
Потому что тесты изолировмны и когда ты выполняешь второй тест, то в базе нет юзера и put не знает, что менять.
С
Хм.. а че так можно? миграции ради пермишенов. Это че мне вношу изменения в таблицу потом инстепкДБ а потом migration делать?
https://medium.com/@gauravtoshniwal/how-to-create-content-types-and-permissions-for-already-created-tables-89a3647ff720
тут показывают как добавить дефолтные пермишены.
я бы ещё попытался избавиться от managed = False - создал бы миграции, пометил их фейковыми и дальше при изменении таблицы создавались бы миграции на изменение.
а миграции можно и руками создавать какие хочешь
тут показывают как добавить дефолтные пермишены.
я бы ещё попытался избавиться от managed = False - создал бы миграции, пометил их фейковыми и дальше при изменении таблицы создавались бы миграции на изменение.
а миграции можно и руками создавать какие хочешь
PZ
django.urls.exceptions.NoReverseMatch: Reverse for 'client_information' with no arguments not found. 1 pattern(s) tried: ['api/v1/client_information/(?P<telegram_id>[^/]+)/$']
То есть с кваргами роут находился и в этом месте все было хорошо.
CR
кто нибудь использовал для апи Bearer?
S
https://medium.com/@gauravtoshniwal/how-to-create-content-types-and-permissions-for-already-created-tables-89a3647ff720
тут показывают как добавить дефолтные пермишены.
я бы ещё попытался избавиться от managed = False - создал бы миграции, пометил их фейковыми и дальше при изменении таблицы создавались бы миграции на изменение.
а миграции можно и руками создавать какие хочешь
тут показывают как добавить дефолтные пермишены.
я бы ещё попытался избавиться от managed = False - создал бы миграции, пометил их фейковыми и дальше при изменении таблицы создавались бы миграции на изменение.
а миграции можно и руками создавать какие хочешь
Спасибо! А от всех managed-false мне не избавиться у меня половина моделей к представлениям обращается)))
С
Спасибо! А от всех managed-false мне не избавиться у меня половина моделей к представлениям обращается)))
это как? структуру БД кто-то другой изменяет?
S
это как? структуру БД кто-то другой изменяет?
База до меня была создана, там сложно все.. На основе таблиц создано много представлений, да и сам добавляю их, а в джанге inspectdb делаю и сразу к полям обращаюсь, все вычесления на БД в таком случае, иначе там связи капец какие, ORM в джанге так не сможет
С
База до меня была создана, там сложно все.. На основе таблиц создано много представлений, да и сам добавляю их, а в джанге inspectdb делаю и сразу к полям обращаюсь, все вычесления на БД в таком случае, иначе там связи капец какие, ORM в джанге так не сможет
если я правильно понял, то много запросов во view напрямую в БД, в обход ORM.
ну ок, БД то всё равно изменять придётся когда-нибудь. это может делать ORM и поэтому лучше поэтапно избавиться от managed=False и не трогать модели лишний раз, если оно не нужно, тогда и запросы будут актуальны.
это упростит добавление пермишн для каждой модели.
ну ок, БД то всё равно изменять придётся когда-нибудь. это может делать ORM и поэтому лучше поэтапно избавиться от managed=False и не трогать модели лишний раз, если оно не нужно, тогда и запросы будут актуальны.
это упростит добавление пермишн для каждой модели.
S
если я правильно понял, то много запросов во view напрямую в БД, в обход ORM.
ну ок, БД то всё равно изменять придётся когда-нибудь. это может делать ORM и поэтому лучше поэтапно избавиться от managed=False и не трогать модели лишний раз, если оно не нужно, тогда и запросы будут актуальны.
это упростит добавление пермишн для каждой модели.
ну ок, БД то всё равно изменять придётся когда-нибудь. это может делать ORM и поэтому лучше поэтапно избавиться от managed=False и не трогать модели лишний раз, если оно не нужно, тогда и запросы будут актуальны.
это упростит добавление пермишн для каждой модели.
ну, на реальных таблицах так и сделаю, но их не много)) есть отчеты которые по апи тянут инфу из представлений, тут пермишн вообще некуда писать.
S
если я правильно понял, то много запросов во view напрямую в БД, в обход ORM.
ну ок, БД то всё равно изменять придётся когда-нибудь. это может делать ORM и поэтому лучше поэтапно избавиться от managed=False и не трогать модели лишний раз, если оно не нужно, тогда и запросы будут актуальны.
это упростит добавление пермишн для каждой модели.
ну ок, БД то всё равно изменять придётся когда-нибудь. это может делать ORM и поэтому лучше поэтапно избавиться от managed=False и не трогать модели лишний раз, если оно не нужно, тогда и запросы будут актуальны.
это упростит добавление пермишн для каждой модели.
вот по этому файлу можете подскакзать https://medium.com/@gauravtoshniwal/how-to-create-content-types-and-permissions-for-already-created-tables-89a3647ff720 так можно прописать любые пермишены и хранить их в одном файле?
M
обязательно ли мигрировать данные в базе в постгре или можно дампом закинуть?
S
если я правильно понял, то много запросов во view напрямую в БД, в обход ORM.
ну ок, БД то всё равно изменять придётся когда-нибудь. это может делать ORM и поэтому лучше поэтапно избавиться от managed=False и не трогать модели лишний раз, если оно не нужно, тогда и запросы будут актуальны.
это упростит добавление пермишн для каждой модели.
ну ок, БД то всё равно изменять придётся когда-нибудь. это может делать ORM и поэтому лучше поэтапно избавиться от managed=False и не трогать модели лишний раз, если оно не нужно, тогда и запросы будут актуальны.
это упростит добавление пермишн для каждой модели.
С
на сколько я понял, он создает дефолтные контент тайп и пермишн. используется это наверняка один раз
S
это а apps.py прописывается?