Конструктор ERP Python+Django

[Djelf]

Не робит.
Считаю что это надо сначала проверять на "чистой" системе, т.е. ну... на эталлоной, поставленной с нуля, а потому уже выкладывать.
И т.п, и т.д. но я бы не сказал что у нас всех "лапки", мы это могём все поправить, но это довольно затруднительно по времени.
Возможно наши системы (разработчиков для 7.7/и восьмой хрени) настолько загажены всяким необходимым, что так это не взлетает.
Образ системы помог бы проще это оценить.

З.Ы. Это не претензия, это пожелание.

[1ex]

Я всегда говорю спасибо...

Так что - Спасибо.

Если время будет - можно (пожалуйста) попросить лог запуска ( можно и в личку)?

Так, то да . Даже у себя локально - запускал на десятке машин. На трех не поднялось совсем. Ощущение было, что борьба с зависимостями ведет на темную сторону Linux...

Винда разная, дрова разные, особенно если у кого mySql стоял. у 1С-ников кстати хуже всего стартануло.

В разработке две ветки. Одна - настольная, под винду (там пакет для шедулера другой), могу собрать виндовый образ под VMware Player, образ будет - чище некуда. Постараюсь на майских запилить. Ссылку положу.

Второй - под linux. Там шедулер - на Кроне. Там могу (правда "лапки" тут присутствуют ) в теории собрать docker образ, если кому надо (но быстро не обещаю)...

[Djelf]

Код Выделить Развернуть

(venv) r:\forTea-main>start.bat
python
r:\forTea-main\venv
""
venv "r:\forTea-main\venv\Scripts\Python.exe"
Traceback (most recent call last):
  File "r:\forTea-main\manage.py", line 11, in main
    from django.core.management import execute_from_command_line
ModuleNotFoundError: No module named 'django'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "r:\forTea-main\manage.py", line 22, in <module>
    main()
    ~~~~^^
  File "r:\forTea-main\manage.py", line 13, in main
    raise ImportError(
    ...<3 lines>...
    ) from exc
ImportError: Couldn't import Django. Are you sure it's installed and available on your PYTHONPATH environment variable? Did you forget to activate a virtual environment?
Для продолжения нажмите любую клавишу . . .

Джанго то стоит, пип его ставил, дальше копаться не стал.

Докер так себе, не охота изучать, один раз поставил так вся система начала дико тормозить, снес - стало как и раньше.
На этом знакомство с докером и закончилось 

Простенькая виртуалочка бы не помешала, лучше наверное на linux, если без всяких офисов с минимальным гуи типо xfce или lxde (xubuntu/lubuntu) то и размер будет приемлимый и лицензионность соблюдена.
Почему именно на основе ubuntu? Да потому что мануалей по ней на порядок больше, чем по остальным вариантам, это упрощает решение странных ситуаций.

[Djelf]

Да, кстати, база sqlite очень грамотно спроектирована, явных косяков не вижу.

Небольшие все таки есть, ну например "value" text NULL CHECK((JSON_VALID ("value") OR "value" IS NULL))
Это много где используется.
Подозреваю что OR "value" IS NULL было добавлено позже первоначального проектирования.

Я бы поменял местами проверки, т.к. оптимизатор в sqlite достаточно дуболомный, чтобы понять что надо переставить проверки местами, а если учесть что JSON_VALID занимает больше времени чем проверка на NULL (что вообще ничего почти не занимает), то это может серьезно поднять скорость работы базы.

А! Вдогонку, sqlite же jsonb держит, перевод на него тоже может несколько ускорить работу. Или там уже jsonb уже используется?

[1ex]

По Linux - принял, сделаю.

По базе...
Эм...
чтобы не соврать - скажу, что sqlite родился из-за порта с mariaDB (та самая родительская ветка с Linux версии и с отдельным DB сервером).

Причем порт был в "лоб" с минимальными поправками для совместимости (чтобы хоть работало .

Понадобился он для локальных разработок (ну там - архив документов с распознаванием поднять на коленке, концепты потестить - в отрыве от серверной), поэтому вот такие "неоптимальности" и есть.
Оптимизации, у меня, обычно в конце списка... НО! про эти неоптимальности - я даже и не подумал.

Спасибо.

Добавил в список косяков .

[1ex]

Я то пишу так:
"
# Справочники
class Designer(models.Model):
    name = models.CharField(max_length=100)
    formula = models.CharField(max_length=100, null=True)
    delay_settings = models.JSONField(default={'handler': None, 'auto_approve': False})
    parent = models.ForeignKey('self', on_delete=models.DO_NOTHING, null=True)
    is_required = models.BooleanField(null=False, default=False)
    default = models.CharField(max_length=500, null=True)
    is_visible = models.BooleanField(default=False)
    priority = models.IntegerField(default=0)
    value = models.JSONField(null=True)
    delay = models.BooleanField(null=True)
    system = models.BooleanField(default=False)
    settings = models.JSONField(null=True)
"

А ORM Django превращает json - в тот самый
"JSONField": "text"

, который в свою очередь превращает его (в элегантные шорты) в

data_type_check_constraints = {
....
JSONField": '(JSON_VALID("%(column)s") OR "%(column)s" IS NULL)',


Вот и получаю лажу неоптимальные хреновины решения.

[Djelf]

Это были предположения, на продакшене возможно что я был не прав.
Проверка на null возможно лишняя, но это опять требует проверки, возможно это проверяется раньше.и эта проверка лишняя.
10 уже лет уже сижу на sqlite (всякие адаптеры ко всякой хрени), для 7.7 это очень сильный буст дла базы
Если будут проблемы с запросами - звони/стучи, не проблема их посмотреть.