… у них отличная команда поддержки и документация. Но что, если нам придется поддерживать код, который не имеет всего этого?
Если в них нету документации тогда в случаи с JS мы вообще не знаем что такое dispatch, тогда как в случаи с TS знаем все интерфейсы (+ IDE помогает)
И для ThunkAction<void, {}, {}, AnyAction> и ThunkDispatch<{}, {}, AnyAction> можно сделать псевдонимы типа AnyThunkActionAnyThunkDispatch если они очень часто используются.
Первое, что бросается в глаза — опять пишется больше кода.
userRoute.ts может виглядет так:
class UserRouter extends Router {
public address = "/users";
list(req: express.Request, res: express.Response) {
//get uesrs from DB
res.json(users);
}
create(req: express.Request, res: express.Response) {
//create user
res.json(userCreated);
}
}
Например так выгладит хендлер для CRUD в Python/Django REST Framework с авторизацией, пагинацией, автогенерацией документации и еще много чего (подскажите аналог для TS/JS):
class UserViewSet(ModelViewSet):
serializer_class = UserSerializer
Где здесь лишний код из за ООП?
П. С.: Лично для меня идеально не писать типы, но чтобы IDE о них знала. В Kotline что-то такое делают.
Я также голосовал по за iPhone пока не смотрел кропи… Баланс белого лучше, детализация хуже.
Правда тут тоже спорно что важнее: соц сети и так режут детализацию, а автоматические фильтры в гугл фото обычно помогают с насыщенностью цветов и балансом белого.
Честно говоря не уверен, что мой пример с С правильный (не успел удалить).
В "строгом" Delphi есть тип PChar (Pointer to char) к которому можно добавить число, но это не мешает ему быть "строгим". Так что, это больше похоже на переопределение методов как в "строгом" Python с "abc" * 3.
Кто-то может привести лучший вариант, почему в С официально слабая типизация? (примеры неявного конвертирования)
At least for the initial release, slots will not be supported. slots needs to be added at class creation time. The Data Class decorator is called after the class is created, so in order to add slots the decorator would have to create a new class, set slots, and return it. Because this behavior is somewhat surprising, the initial version of Data Classes will not support automatically setting slots.
Один запрещает использовать глаголы в URI; второй разрешает только те, которые нельзя выразить с помощью HTTP-методов, используя для этого свои понятия, которые отсутствуют в REST. Другие же честно разделяют обязательные и необязательные ограничения. Это порождает просто чудовищную путаницу в головах, превращая REST в хреновину, которую никто не может может толком описать.
Не согласен, но сейчас не об этом.
он ничем не лучше.
Я скажу чем хуже: +одно слово +0 информации (не я один такой умный, поэтому, это уже описали в этих "tips")
Вы согласны?
Повторю вопрос:
В стандартном, указаном вами, гайде в разделе в разделе Never use CRUD function names in URIs предлагают делать DELETE /, но вы защищаете вариант с DELETE /delete
(пожалуйста не расширяйте фокус вопроса. можете даже проигнорировать то что сверху и ответить только на следующий вопрос)
При этом ~0,2 А уходит на его текущую работу в спящем режиме.
В этом обзоре сказано, что P9 Lite держится 79 часов в режиме ожидания что равно: 3000мАг / 79г * 3.7В = 140.5 мВт
Что сильно меньше указанных вами 0.2А * 5В = 1000 мВт
1Вт это потребления во время "web browsing" 3000мАг / 12г * 3.7В = 925мВт
DRF это all-inclusive где с коробки есть почти всё что нужно для большинства сервисов.
Благодаря этому для него есть много плагинов, потому что автор плагина знает "ага раз DRF значить Django ORM, DRF Serializers/Views/etc."
С другой стороны есть Flask компоненты для которого нужно собирать словно кубики лего что требует траты много времени на исследованные всех "кубиков". Они к тому же очень часто не совместимы между собой.
А FastAPI это где то по середине. (ближе к Flask, но со некоторыми фишками)
Хм. В варианте с inner join ошибка: должно быть не "IS NOT NULL", а "IS NULL".
По експлейнах вижу Seq Scan on products в случаи с JOIN.
Интересно что будет если все условия перенести в JOIN:
SELECT COUNT(*) FROM "listings"
INNER JOIN "products" ON products.id = listings.source_id and (
"products"."site_id" IS NULL OR "products"."item_id" IS NULL
);
Ну я же говорил, что это из моей личной коллекции «Как не надо писать SQL» :-D
Не увидел, виноват (главное читал же комент))
И, хоть это немного и контринтуитивно, но такой вариант с подзапросом работает ощутимо быстрее вашего примера с JOIN (1 секунда против 8), хотя я сам думал, что ваш будет быстрее.
SELECT COUNT(*) FROM "listings"
INNER JOIN "products" ON products.id = listings.source_id
WHERE "products"."site_id" IS NOT NULL AND "products"."item_id" IS NOT NULL
то есть без sub query в where которая исполняеться для каждой строчки listing.
Можете, пожалуйста, показать OpenAPI документацию по этому ендпоинту? А то, мне сложно понять зачем всё это)
Ctrl+Click обычно помагает.
Если в них нету документации тогда в случаи с JS мы вообще не знаем что такое
dispatch
, тогда как в случаи с TS знаем все интерфейсы (+ IDE помогает)И для
ThunkAction<void, {}, {}, AnyAction>
иThunkDispatch<{}, {}, AnyAction>
можно сделать псевдонимы типаAnyThunkAction
AnyThunkDispatch
если они очень часто используются.userRoute.ts может виглядет так:
Например так выгладит хендлер для CRUD в Python/Django REST Framework с авторизацией, пагинацией, автогенерацией документации и еще много чего (подскажите аналог для TS/JS):
Где здесь лишний код из за ООП?
П. С.: Лично для меня идеально не писать типы, но чтобы IDE о них знала. В Kotline что-то такое делают.
Я также голосовал по за iPhone пока не смотрел кропи… Баланс белого лучше, детализация хуже.
Правда тут тоже спорно что важнее: соц сети и так режут детализацию, а автоматические фильтры в гугл фото обычно помогают с насыщенностью цветов и балансом белого.
Честно говоря не уверен, что мой пример с С правильный (не успел удалить).
В "строгом" Delphi есть тип
PChar
(Pointer to char) к которому можно добавить число, но это не мешает ему быть "строгим". Так что, это больше похоже на переопределение методов как в "строгом" Python с"abc" * 3
.Кто-то может привести лучший вариант, почему в С официально слабая типизация? (примеры неявного конвертирования)
Это проблемы слабой, а не динамической типизации.
Пример на C:
(да, я знаю, что стринга, это указатель в C)
https://www.python.org/dev/peps/pep-0557/#support-for-automatically-setting-slots
dockerfile в котором всё работает было бы идеально. А то у всех проблемы разные :)
пожалуйста, выберите один пример и мы обсудим
Лично я говорил только о
DELETE /delete
vsDELETE /
.И мы сошлисть на том, что пункт "Never use CRUD function names in URIs" оправдан. Можно пройтись и по другим пунктам.
Это всё что я хотел сказать.
Нет.
Не согласен, но сейчас не об этом.
Я скажу чем хуже: +одно слово +0 информации (не я один такой умный, поэтому, это уже описали в этих "tips")
Вы согласны?
Повторю вопрос:
В стандартном, указаном вами, гайде в разделе в разделе Never use CRUD function names in URIs предлагают делать
DELETE /
, но вы защищаете вариант сDELETE /delete
(пожалуйста не расширяйте фокус вопроса. можете даже проигнорировать то что сверху и ответить только на следующий вопрос)
Чем
DELETE /delete
лучше заDELETE /
?В этом обзоре сказано, что P9 Lite держится 79 часов в режиме ожидания что равно:
3000мАг / 79г * 3.7В = 140.5 мВт
Что сильно меньше указанных вами
0.2А * 5В = 1000 мВт
1Вт это потребления во время "web browsing"
3000мАг / 12г * 3.7В = 925мВт
Вы правы, тип ошибки указана не верно. Но всё же она есть, согласны?
Есть основной стиль, а есть "все другие".
Чем
DELETE /delete
лучше заDELETE /
?Ну не стандарту, а стандартному стайл гайду. Это ничего не меняет.
Зачем писать:
вместо стандартного:
это то же самое что писать коментарии типа:
n += 2 # add 2 to n
— никакой новой информацииМое ИМХО:
DRF это all-inclusive где с коробки есть почти всё что нужно для большинства сервисов.
Благодаря этому для него есть много плагинов, потому что автор плагина знает "ага раз DRF значить Django ORM, DRF Serializers/Views/etc."
С другой стороны есть Flask компоненты для которого нужно собирать словно кубики лего что требует траты много времени на исследованные всех "кубиков". Они к тому же очень часто не совместимы между собой.
А FastAPI это где то по середине. (ближе к Flask, но со некоторыми фишками)
Я бы пока брал DRF для продакшена.
можно проще:
Хм. В варианте с inner join ошибка: должно быть не "IS NOT NULL", а "IS NULL".
По експлейнах вижу
Seq Scan on products
в случаи с JOIN.Интересно что будет если все условия перенести в JOIN:
Не увидел, виноват (главное читал же комент))
Не знал о таком. Спасибо)
Мне кажеться та будет быстрее:
то есть без
sub query
вwhere
которая исполняеться для каждой строчкиlisting
.Проблема будет при обращении к self внутри проперти: