Django Web Framework: The 'D' is silent dumbass

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Django Web Framework: The 'D' is silent dumbass

galenanorth: May 19, 2016

If you set null=True and default=0 on the same field, is the null=True setting ignored? I had written some of my optional fields with "blank=True, null=True, default=0", so I was going back through them and changing them.

# ¿ Dec 30, 2016 11:50

Adbot: ADBOT LOVES YOU

# ¿ May 15, 2024 13:55

galenanorth: May 19, 2016

I'll be using Django for web scraping to collect data for a business-to-business data service, mainly for business locations. Someone might be using or viewing parts of the PostgreSQL database directly. I want to make it easier to see which columns go with which table during joins or complex queries by using a custom naming convention.

The default table name is appname_modelname, and Django doesn't convert the CamelCase model name convention into snake_case. Using the db_table option, the default appname_modelname for the table becomes model_name.

Using the db_column option, the default field_name for the column becomes table_name_column_name. The id column becomes table_name_id. The purpose behind this convention is that during a join or complex query, or when different models have the same field names (e.g. first_name), it will make it easier to see which column goes with which table. Particularly, the foreign key will stand out. If there were a product table (using a hypothetical unrelated to the project), its column headers would be product_id, product_description, vendor_id, product_purchase_date, product_price.

Is this going to cause difficulty down the line? Removing the appname_ prefix might lead to a higher chance of naming conflicts, but leaving it would make writing SQL queries take slightly longer. Looking at my PostgreSQL textbook, which uses app_name.table_name, it doesn't look like they'll be that much longer and there are always aliases

Edit: Also, for naming indexes, I'll use {tablename}_{columnname(s)}_idx. This is PostgreSQL's system for default index naming, and it's used automatically behind-the-scenes when PostgreSQL creates constraints. Django shortens index names to 30 characters for compatibility with Oracle, but I'd like the names to be easier to read and more predictable, so if I accidentally break something and have to go into the DBMS, the SQL environment will feel familiar

galenanorth fucked around with this message at 21:45 on Mar 12, 2023

# ¿ Mar 2, 2023 20:56

galenanorth: May 19, 2016

A few years back, I tried making a website called for adopting cats or reporting lost/found cats, called Meowseum. Unfortunately, I got sidetracked on allowing videos of cats to be uploaded, which it turns out is very complicated, and I also got sidetracked on validating and processing (e.g. automatically scaling) images, which is also very complicated. As such, the project has such a long and complicated dependency tree that it may have collapsed under its own weight.

My hard drive failed, but I backed up the data. When I got a new hard drive and upgraded from Python 3.5 to Python 3.11, the project stopped working. A lot of my packages are in the directory site-packages_editable because I'd used the following command to make the packages support version control with Git.

code:

python -m pip install --upgrade -e git+[URL_ending_in .git]@[version_tag]#egg=[project_name] --src [directory]

Most of these packages had bug fixes that I didn't bother fixing in the main repository, because I was being lazy, but there were also some edits I made to Django for development purposes. For example, I wanted to make users be able to log in via email, so I went to C:\Program Files\Python311\Lib\site-packages\django\contrib\auth\models.py. Then I on AbstractUser's email field, I set unique=True and remove blank=True to make it required. This way, you can indirectly obtain the username from the email address with a query. I'm not sure if there are better ways to do that -- I think I , but I thought it was the only way at the time.

I tried simply copying over site-packages and site-packages_editable, which made "import django" work in the Python shell, but I get the that led to the error

code:

$ python manage.py runserver 127.0.0.1:8000
Traceback (most recent call last):
  File "A:\A\Web and software development workspace\My websites\Meowseum_Project\manage.py", line 8, in <module>
    from django.core.management import execute_from_command_line
ModuleNotFoundError: No module named 'django.core'

I think the problem is that it expects Django to be installed using "pip install django". The directory tree of the editable install is different, so I moved django/django to the parent directory and tried running it again. That led to the error

code:

$ python manage.py runserver 127.0.0.1:8000
Traceback (most recent call last):
  File "A:\A\Web and software development workspace\My websites\Meowseum_Project\manage.py", line 8, in <module>
    from django.core.management import execute_from_command_line
  File "C:\Program Files\Python311\Lib\site-packages\django\core\management\__init__.py", line 10, in <module>
    from django.apps import apps
  File "C:\Program Files\Python311\Lib\site-packages\django\apps\__init__.py", line 1, in <module>
    from .config import AppConfig
ModuleNotFoundError: No module named 'django.apps.config'

I think I'm going to have to install every single package exactly the same way I did before. This will take a while, because my back-end dependency tree looks like

code:

* indicates that I edited the package, so the edits will have to be copied over
- Python 3.5. It has to be 3.5 to avoid compatibility errors with Django 1.11, like when Python 3.10 [url=https://stackoverflow.com/questions/72032032/importerror-cannot-import-name-iterable-from-collections-in-python]changed collections module syntax[/url] Originally the Python was 32-bit because python-magic only supported 32-bit Python, but python-magic has since added 64-bit support.
- django 1.11.6*
- postgreSQL 10.0, 64-bit
  On the production server, 9.4 was the version I previously used.
- psycopg2-binary-2.8.6
  I originally wrote "win-psycopg 2-2.6.2 on development server", but running "python -m pip install psycopg2-binary" resolved the error message when I reinstalled.
- pytz 2017.2 (installed to site-packages)
  Provides datetimes with SQLLite on the development server
- django-hitcount 1.2.2
  - pytz 2017.2
- django-ipware 1.1.6
  - django-hitcount 1.2.2*

File upload process:
- python-magic 0.4.12
  - File for Windows 5.03
- pymediainfo 2.1.5
- Pillow 4.0.0 (installed to site-packages)
  - olefile v0.44
- JHEAD.exe 3.0 for stripping EXIF data
- ImageMagick's convert.exe for EXIF orientation
  at C:\Program Files\ImageMagick-7.0.5-4-portable-Q16-x64\convert.exe
- ffmpeg.exe N-83882-g580bbc on development server (03/2017, autorot added)
  ffmpeg.exe 3.2.4 on production server (03/2017).
- qtfaststart 1.8.0
- moviepy==v0.2.2.13*
  - tqdm 4.10.0
  - decorator 4.0.10
  - imageio 2.1.2
  - numpy 1.11.2
    - cython 0.27
  - ffmpeg

As an aside, site-packages_editable also has some packages that I didn't edit, because they're dependencies of the ones I did edit. For example, pip installed a copy of pytz to both the site-packages and site-packages_editable folders.

Maybe I should give up and start over. If I start fresh, I could upgrade to Django 5.0 and use React for the front-end instead of using only Django templates. I'd try much harder to avoid editing packages without having the Git repository incorporate my changes in the future. Maybe I'd run into the same problem again, so I should face this head-on by installing every package one by one and then manually copying over my old edits. I used the command

code:

python -m pip install --upgrade -e git+https://github.com/django/django.git@1.11.6#egg=django --src "C:\Program Files\Python35\Lib\site-packages"

but I can't integrate my changes by copying over the directory, or else the same ModuleNotFoundError: No module named 'django.apps.config' error occurs. When I went through with installing all the packages unedited and launching it anyway, it told me that Django was working fine, but there were 21 migrations to be made. I got "Exception Type: OperationalError at / Exception Value: no such table: Meowseum_exceptionrecord" (traceback)
which I assume refers to my ExceptionRecord model for saving exception data to the database itself for debugging. I tried to migrate, and Django won't even let me migrate. I got "django.db.utils.OperationalError: near "[]": syntax error" when I ran that.

I'm thinking I should just give up, and if I work on Django again, just start all over with some other idea

Edit: I found out from an online chat that the django.db.utils.OperationalError exception was caused by trying to switch back to SQLite after developing with Postgres, and the page has information on switching back

galenanorth fucked around with this message at 04:30 on May 13, 2024

# ¿ May 12, 2024 00:32

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Django Web Framework: The 'D' is silent dumbass