LINUX.ORG.RU

django не видит базу данных sqlite3

 , ,


0

2

Есть проект на джанго, раньше работал, сейчас не видит базу данных sqlite3.

models.py

from django.db import models

# My models are here.

cyrillic_letters = {
    'а': 'a',
    'б': 'b',
    'в': 'v',
    'г': 'g',
    'д': 'd',
    'е': 'e',
    'ё': 'e',
    'ж': 'zh',
    'з': 'z',
    'и': 'i',
    'й': 'j',
    'к': 'k',
    'л': 'l',
    'м': 'm',
    'н': 'n',
    'о': 'o',
    'п': 'p',
    'р': 'r',
    'с': 's',
    'т': 't',
    'у': '',
    'ф': 'f',
    'х': 'h',
    'ц': 'ts',
    'ч': 'ch',
    'ш': 'sh',
    'щ': 'sch',
    'ъ': '',
    'ы': 'y',
    'ь': '',
    'э': 'e',
    'ю': 'j',
    'я': 'ja',
    'А': 'A',
    'Б': 'B',
    'В': 'V',
    'Г': 'G',
    'Д': 'D',
    'Е': 'E',
    'Ё': 'E',
    'Ж': 'ZH',
    'З': 'Z',
    'И': 'I',
    'Й': 'J',
    'К': 'K',
    'Л': 'L',
    'М': 'M',
    'Н': 'N',
    'О': 'O',
    'П': 'P',
    'Р': 'R',
    'С': 'S',
    'Т': 'T',
    'У': '',
    'Ф': 'F',
    'Х': 'H',
    'Ц': 'TS',
    'Ч': 'CH',
    'Ш': 'SH',
    'Щ': 'SCH',
    'Ъ': '',
    'Ы': 'Y',
    'Ь': '',
    'Э': 'E',
    'Ю': 'J',
    'Я': 'JA',
    ' ': '_',
}


def cyrillic2latin(text):
    tmp = ''
    for ch in text:
        tmp += cyrillic_letters.get(ch, ch)
    return tmp


class User(models.Model,):
    id = models.IntegerField(verbose_name='ID',
                             unique=True, primary_key=True)
    nick = models.CharField(max_length=100,
                            verbose_name='Никнейм',
                            unique=True, blank=True)
    name = models.CharField(max_length=100,
                            verbose_name='Реальные имя и фамилия',
                            default='')
    password = models.CharField(max_length=100,
                                verbose_name='Пароль', default='123123')
    permissions = models.IntegerField(verbose_name='Возможности', default=0)
    slug = models.CharField(max_length=100,
                            verbose_name='Slug (не трогать)',
                            unique=True, blank=True, )

    class Meta:
        verbose_name = 'Информация о пользователе'
        verbose_name_plural = 'Информация о пользователях'

    def __str__(self, ):
        return self.name

    def save(self, *args, **kwargs):
        if not self.nick or self.nick == '' or self.nick == ' ':
            self.nick = self.name
        # self.nick = cyrillic2latin(self.nick) [i shall not convert nicks]
        self.slug = cyrillic2latin(self.nick)
        super().save(*args, **kwargs)


class Article(models.Model, ):
    id = models.IntegerField(verbose_name='ID',
                             unique=True, primary_key=True)
    date = models.DateTimeField(verbose_name='Время написания', unique=True)
    name = models.CharField(max_length=100,
                            verbose_name='Название статьи',
                            default='***')
    text = models.CharField(max_length=2 ** 10, verbose_name='Текст', default='Я опять забыл написать текст :(')
    slug = models.CharField(max_length=100,
                            verbose_name='Slug (не трогать)',
                            unique=True, blank=True, )

    class Meta:
        verbose_name = 'Информация о пользователе'
        verbose_name_plural = 'Информация о пользователях'

    def __init__(self, *args, **kwargs):
        super().__init__(args, kwargs)
        self.nick = None

    def __str__(self, ):
        return self.name

    def save(self, *args, **kwargs):
        if not self.nick or self.nick == '' or self.nick == ' ':
            self.nick = self.name
        # self.nick = cyrillic2latin(self.nick) [i shall not convert nicks]
        self.slug = cyrillic2latin(self.nick)
        super().save(*args, **kwargs)

Зарегистрировал в admin.py эти классы, запускаю сервер джанго, захожу в админку и вижу, что джанго не показывает эти классы в таблице, несмотря на то, что раньше всё работало. sqlitestudio читает БД и находит два объекта класса User, которые были в БД.

Весь интернет обгуглил и ничего не нашёл. От чего это может быть и как это починить?

Ответ на: комментарий от x3al

Да, BASE_DIR / 'db.sqlite3'. БД лежит в корне проекта. Пробовал менять на абсолютный путь /home/t0ngub1n/PycharmProjects/FirstSite/db.sqlite3 – ничего не поменялось

tongubin ()
Последнее исправление: tongubin (всего исправлений: 1)
Ответ на: комментарий от tongubin

Тогда остаются варианты вроде «get_queryset() в admin.py переписан и отфильтровывает варианты», «админка пытается вытащить не тот класс» и «при запуске почему-то юзается другой DJANGO_SETTINGS_MODULE».

Что можно сделать:

  • Руками написать get_queryset() в админ-классе и поставить брейк дебаггера там чтобы увидеть что вообще происходит
  • Либо попробовать manage.py shell, from .models import User, User.objects.all() чтобы убедиться, что это вообще видится.
x3al ★★★★★ ()
Ответ на: комментарий от x3al
>>> from .models import User
Traceback (most recent call last):
  File "/usr/lib/python3.8/code.py", line 90, in runcode
    exec(code, self.locals)
  File "<console>", line 1, in <module>
KeyError: "'__name__' not in globals"

upd. models лежит в папке FirstApp. Я заменил .models на FirstApp.models в admin и views, но это не помогло

upd2. from FirstApp.models import User ничего не выдает, User.objects.all() выдаёт имена двух юзеров

tongubin ()
Последнее исправление: tongubin (всего исправлений: 3)
Ответ на: комментарий от tongubin

User.objects.all() выдаёт имена двух юзеров

Вывод: проблема в админке. Может, ты регистрируешь django.contrib.auth.models.User вместо своего User?

x3al ★★★★★ ()
Ответ на: комментарий от gruy
Ответ на: комментарий от tongubin

Что это за порнография по этой ссылке?

Для кода существуют, например, gist.github.com. Там его можно посмотреть без скачивания, раззиповывания, и с подсветкой синтаксиса.

По проблеме надо смотреть: а) созданы ли миграции б) применены ли миграции в) код админки

Вместо

    slug = models.CharField(max_length=100,
                            verbose_name='Slug (не трогать)',
                            unique=True, blank=True, )

Лучше добавить editable=False, поле нельзя будет редактировать, это надёжнее комментариев «не трогать»

def cyrillic2latin(text):
    tmp = ''
    for ch in text:
        tmp += cyrillic_letters.get(ch, ch)
    return tmp

Можно заменить на гораздо более эффективную и читаемую версию

    return ''.join(cyrillic_letters.get(ch, ch) for ch in text)

Вообще, вместо всей этой колбасы можно позаимствовать код из встроенной функции slugify Django (или третьесторонних пакетов для генерации слагов для кириллицы).

Первичный ключ id добавляется Django без явного указания. primary_key=True уже подразумевает unique=True.

emorozov ()
Ответ на: комментарий от emorozov

django не добавляет айди. и primary_key ничего не значит, я так создавал два одинаковыx айдишника с primary_key и без unique

код админки в архиве есть. про гист.гитхаб не знал, буду знать

миграции применены и проходят без ошибок

tongubin ()
Последнее исправление: tongubin (всего исправлений: 2)
Ответ на: комментарий от tongubin

django не добавляет айди

Это самые-самые основы Django. Вот тут, прямо первые 3-4 абзаца: https://docs.djangoproject.com/en/3.2/topics/db/models/

Загляни в любой Django проект, 95-100% моделей будут без явного определения колонки id, т.к. Django добавляет её автоматически всегда, если только первичный ключ не задан явно по каким-то причинам.

primary_key ничего не значит, я так создавал два одинаковыx айдишника с primary_key и без unique

Вот одно из определений primary key: Primary Key is a column that is used to uniquely identify each tuple of the table.

Если тебе удавалось создать два id с primary key, то ты точно что-то сделал не так: или не создал primary key, или не применил миграцию с ним, или как-то неправильно проверял вставку одинаковых айдишников.

Это прямо основы-основ, что-то настолько базовое, как сказать: «Я нажал кнопку и свет не зажёгся, значит электричества не существует».

код админки в архиве есть. про гист.гитхаб не знал, буду знать

Мне этот порносайт архив не показывает. Я вижу только какую-то страницу с кучей разноцветных элементов, по которым невозможно понять, есть там архив или нет, и как его скачать.

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

Чтобы посмотрели, надо сделать информацию максимально доступной.

Но даже не глядя, предполагаю, что скорее всего что-то с админкой не так. Например, классы написаны, но не зарегистрированы (admin.site.register) или неправильно зарегистрированы.

emorozov ()
Ответ на: комментарий от gruy

https://github.com/t0ngub1n/mysite мой репо. venv и manage.py нет

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

tongubin ()
Последнее исправление: tongubin (всего исправлений: 2)
Ответ на: комментарий от tongubin

Нет __init__.py, manage.py…

Может, проще доверить работу с git тому, кто умеет это делать? В смысле тому, кто может git add ., git commit и git push сделать?

x3al ★★★★★ ()
Последнее исправление: x3al (всего исправлений: 1)
Ответ на: комментарий от tongubin

Вообще ничего не понял. В репе нет manage.py, как и модуля views.py.

Добавил вручную manage.py, ссылки на views удалил, т.к. по описанию проблема в админке.

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

Лев, почитай книжки по Python’у, почитай официальный tutorial Django. Если не знаешь английский, то он переводился, возможно, перевод уже немного устарел, но это лучше, чем ничего.

То, что ты делаешь… Очень непитонично, мягко говоря. Например, в Python сильно непринято использовать CamelCase для названия приложений и модулей. Вот прям аж глаза режет, насколько непринято.

Потом, ты создаёшь класс User, хотя используешь django.contrib.auth.models.User. Потом у тебя возникнет путаница и ты начнёшь задавать вопросы «А почему я не могу войти в админку, или почему Django не может найти атрибут slug у пользователя Лев?».

Ну и самое главное, ты заблудился в трёх соснах, и не видишь в админке свои модели, хотя я не поленился, потратил полчаса драгоценного времени, и проверил, что всё там есть.

Неэффективно учиться нахрапом, надёргав строку оттуда, строку отсюда, без реального понимания. У Django просто офигительная документация, начни с чтения её. Подряд, не прыгая туда-сюда, чтобы скорее набросать что попало, а потом методом тыка исправлять каждую ошибку, пока не заработает. Это подход PHPстов, и он плохой. :)

emorozov ()
Ответ на: комментарий от tz4678

Для тролля слишком много усилий, мне кажется. :)

Для школьника вроде как неплохой уровень. Я видел хуже у далеко не школьников. Но местами сильно удивляет… Например, я уже забыл, когда видел человека, не умеющего вообще пользоваться git.

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

emorozov ()
Последнее исправление: emorozov (всего исправлений: 1)
Ответ на: комментарий от emorozov

не мог никак разобраться с гитом, сейчас осилил. https://github.com/t0ngub1n/mysite

в админке модели есть и регистрация через форму на index.html проходит, но логин через ту же форму – нет. не могу понять, в чем проблема

tongubin ()
Последнее исправление: tongubin (всего исправлений: 1)
Ответ на: комментарий от tongubin

Несколько замечаний:

from FirstApp.models import *

Импорты со звёздочкой — огромное зло, никогда не используй их! Перечисли то, что импортируешь, явно.

Иначе у тебя уже через пару недель приложение превратится в кашу, в которой будет не разобраться. Тем более, что у тебя модели приложения называются совершенно одинаково со встроенными моделями Django.

Уже через месяц ты сам начнёшь в них путаться, а никто посторонний тем более не сможет разобраться.

Ты, похоже, пытаешься реализовать самостоятельно систему аутентификации/авторизации, но тебе явно не хватает понимания в некоторых местах.

Например, грубая ошибка: хранить пароль в открытом виде в БД. В БД можно хранить только хэш пароля.

Кроме того, любой левый чувак сможет в твоей системе войти с правами любого пользователя, просто перебирая значения user_id в сессии.

Чтобы не заморачиваться этими вопросами, используй django.contrib.auth, в котором всё это уже реализовано правильно. Изобретать велосипеды вредно.

Можешь задействовать библиотеку django-allauth, которая позволит быстро накидать формы логина/регистрации поверх django.contrib.auth (она поддерживает ещё много вещей, но использую её даже если социальная регистрация не нужна).

Для перехода в админку не нужна ссылка. Этот POST формы не залогинит пользователя в админку никаким образом. К тому же, админка основана на пользователях Django из django.contrib.auth, о твоих кастомных пользователях она ничего не знает и работать с ними никогда не будет.

emorozov ()

Десятилетний веб разработчик Антошка? Ну ну…

Дует теплый ветер = в лицо
Шульман мне поправил - яйцо ...

Владимир

anonymous ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.