Попробуйте это
$username = $_POST['username'];
$password = $_POST['password'];
$result = mysqli_query('SELECT * FROM Users WHERE UserName LIKE $username');
if($result){
while($row = mysqli_fetch_array($result))
{
echo $row['FirstName'];
}
}
У вас есть два внешних ключа для пользователя. Django автоматически создает обратное отношение от пользователя к GameClaim, обычно gameclaim_set
. Однако, поскольку у вас есть два FK, у вас будет два атрибута gameclaim_set
, что, очевидно, невозможно. Поэтому вам нужно указать Django, какое имя использовать для обратного отношения.
Использовать атрибут related_name
в определении FK. например,
class GameClaim(models.Model):
target = models.ForeignKey(User, related_name='gameclaim_targets')
claimer = models.ForeignKey(User, related_name='gameclaim_users')
isAccepted = models.BooleanField()
Кажется, я иногда сталкивался с этим, когда добавляю подмодуль в качестве приложения к проекту django, например, учитывая следующую структуру:
myapp/
myapp/module/
myapp/module/models.py
Если я добавлю следующее в INSTALLED_APPS:
'myapp',
'myapp.module',
Кажется, что Django обрабатывает файл myapp.mymodule models.py дважды и выдает указанную выше ошибку. Это можно решить, не включая основной модуль в списке INSTALLED_APPS:
'myapp.module',
Включение myapp
вместо myapp.module
приводит к созданию всех таблиц базы данных с неправильными именами, поэтому это кажется чтобы быть правильным способом сделать это.
Я столкнулся с этим сообщением, ища решение этой проблемы, поэтому решил, что я поставил бы это здесь:)
Просто добавив ответ Джордана (спасибо за отзыв Jordan), это также может произойти, если вы импортируете уровень над приложениями, а затем импортируете приложения, например
myproject/
apps/
foo_app/
bar_app/
Поэтому, если вы импортируете приложения, foo_app и bar_app, тогда вы можете получить эту проблему. У меня были приложения, foo_app и bar_app, все перечисленные в настройках.INSTALLED_APPS
И все же вы хотите избежать импорта приложений, потому что тогда у вас есть одно и то же приложение, установленное в 2 разных пространствах имен
apps.foo_app
и foo_app
OP не использует абстрактный базовый класс ... но если вы, то обнаружите, что жесткое кодирование связанного_имя в FK (например ..., related_name = "myname") приведет к ряду эти ошибки конфликтов - по одному для каждого унаследованного класса из базового класса. В приведенной ниже ссылке содержится обходной путь, который прост, но определенно не очевиден.
Из django docs ...
Если вы используете атрибут related_name на сервере ForeignKey или ManyToManyField, вы всегда должны указывать уникальное обратное имя для этого поля. Это обычно вызывает проблему в абстрактных базовых классах, поскольку поля этого класса включаются в каждый из дочерних классов с одинаковыми значениями для атрибутов (включая related_name) каждый раз.
blockquote>Подробнее здесь .
Иногда вам нужно использовать дополнительное форматирование в related_name
- фактически, в любое время, когда используется наследование.
class Value(models.Model):
value = models.DecimalField(decimal_places=2, max_digits=5)
animal = models.ForeignKey(
Animal, related_name="%(app_label)s_%(class)s_related")
class Meta:
abstract = True
class Height(Value):
pass
class Weigth(Value):
pass
class Length(Value):
pass
Нет столкновения здесь, но связанное имя определено один раз, и Django позаботится о создании уникальные имена отношений.
, тогда у детей класса Value вы получите доступ к:
herdboard_height_related
herdboard_lenght_related
herdboard_weight_related