FloatField?

там скорее всего будет потеря точности, для float типов

Мне надо чтобы в пайтоне это было бы как Decimal тип

вещественное число с указанной точностью до 131072 цифр до десятичной точки и до 16383 — после
если в numeric лимиты не указаны, то psql берёт вот это. Можно эти цифры в джангу скормить.

Да, благодарю. Выглядит как решение.

И в чем проблема?

value = models.DecimalField(max_digits=131072, decimal_places=16383)
— такие цифры скормить не получается, тут уже ругается postgresql:
django.db.utils.DataError: NUMERIC precision 131072 must be between 1 and 1000

Т.е. поля в постгресе:

value1 numeric
value2 numeric(x,y)

— получается все ж разные.

в postgres есть такое ограничение (нельзя руками указать более 1000), я надеялся, что через джангу оно не сработает.
А если сделать таблицу в psq, а потом ./manage.py inspectdb?

Открываю для себя новые возможности джанги, про inspectdb не знал )

from django.db import models


class Data(models.Model):
   value = models.DecimalField(max_digits=65535, decimal_places=65535)

   class Meta:
       managed = False
       db_table = 'data'

— результат работы inspectdb для таблицы, которая была создана как:
CREATE TABLE data (
   id SERIAL PRIMARY KEY,
   value numeric NOT NULL
);

Т.е. все равно используются эти max_digits и dicimal_places

Похоже невозможно через джангу сделать безлимитный numeric

Конечно для моего проекта хватит и value = models.DecimalField(max_digits=1000, decimal_places=500)

Но все равно, не хотелось задавать никаких лимитов, так как по факту я их просто не знаю.

возможно на гитхабе в ишью есть что-нибудь на эту тему, искать надо.

value = models.DecimalField(max_digits=1000, decimal_places=500)

— это не может быть как замена для поля типа numeric()

Там как если делаем поле numeric(1000, 500), то при добавлении числа, например, 1.3, мы в базе будем иметь 1.300000…. и так 500 нулей.

А у меня данные могут быть что 99% имеет всего два знака после запятой, и лишь несколько строк имеют сильно больше знаков.
Видимо придется написать свой  кастомный field type.

форматируй на выводе

А в БД думаешь там все хранится без этих нулей? Я боюсь что в БД все эти нули тоже хранятся. А база большая, и места на это очень много будет тратиться.

Numeric values are physically stored without any extra leading or trailing zeroes. Thus, the declared precision and scale of a column are maximums, not fixed allocations. (In this sense the numeric type is more akin to varchar(n) than to char(n).) The actual storage requirement is two bytes for each group of four decimal digits, plus three to eight bytes overhead.

^^^

Всегда волновал такой вопрос - Нормально ли циклом делать таски в celery?

Благодарю. Да, тогда на самом деле можно пользоваться models.DecimalField(max_digits=1000, decimal_places=500)
А на выводе просто сделать форматтер. Так как чаще всего эти форматтеры так и так приходится писать для таких данных.

Ребят! На сколько хорошо, генерировать уникальный код к заказу, таким образом вызывая в save() методе:

На сколько большая вероятность того, что рандомайзер будет постоянно попадать на уже существующие,
и запускать функцию снова. И на сколько вероятно, затормаживание создания заказа из-за этого?

Допустим поток будет, 100 заказов в день, и они будут оставаться в базе, не удаляться.

def generate_order_id(self):
   """" Generation order code id """
   order_code = ''.join(random.choice(string.digits) for i in range(7))
   if Orders.objects.filter(order_id=order_code).exists():
       return self.generate_order_id()
   return order_code

напиши тест: складывай номера в set(), генери их в цикле (ну хотя бы до 100.000, это три года работы кода при 100 заказах в день) и смотри, как быстро начнутся первые коллизии и сколько они будут разруливаться ближе к концу работы.