djangoappengine 用户创建和数据持久性被破坏
我最近更新到了 appengine SDK 1.6,但在开发环境中保存数据时遇到了问题。我根据官方安装指南进行了所有设置。
尽管我之前为我的应用程序设置了超级用户帐户,但它不再起作用。我再次创建了该帐户
manage.py createsuperuser
,它似乎做了它应该做的事情,但管理员登录不起作用。另外,每次我运行
manage.py syncdb
该脚本时,都会不断通知我,我刚刚安装了身份验证系统,并且还没有任何用户。然后它提示我创建一个超级用户。
因为没有任何内容是持久的,所以我无法登录管理页面,并且我尝试使用内置 shell 保存的任何数据也不会保留。
I recently updated to appengine SDK 1.6 and I'm having trouble with persisting data on my dev environment. I have everything setup according to the official installation guide.
Even though I had a super user account setup for my app previously, it no longer works. I created the account again with
manage.py createsuperuser
and it seems to do what it's supposed to but the admin login doesn't work. Also, every time I run
manage.py syncdb
The script keeps informing me that I just install the auth system and don't have any users yet. Then it prompts me to create a super user.
Because nothing is persisting, I can't login to the admin page and any data I attempt to save using the built in shell doesn't keep either.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您是否有可能在问题跟踪器 https://github.com/django 上发起新问题-nonrel/djangoappengine/issues 或邮件列表 http://groups.google.com/group/django-non-relational ?我认为某处可能存在错误。
is it possible that you fire up a new issue at the issue tracker https://github.com/django-nonrel/djangoappengine/issues or at the mailing list http://groups.google.com/group/django-non-relational ? I think there might be a bug somewhere.
根据您升级的版本,您之前可能没有 '默认分区'值 - 早期版本没有默认设置,但最近的版本使用'dev:'。尝试为
manage.py
提供一个--default_partition
参数。Depending on what you upgraded from, it's possible that you previously had no 'default partition' value - earlier versions didn't set one by default, but recent ones use 'dev:'. Try giving a
--default_partition
argument tomanage.py
.我最终没有进行任何更改,但第二天在我的 Win 7 机器上再次尝试后,问题不存在,因此不幸的是现在无法重现。也许在安装后注销并重新登录会改变某种类型的状态,这是我最好的猜测。抱歉,我没有任何进一步的信息。
I didn't end up changing anything but after trying it again on my Win 7 machine the next day, the issue wasn't there so it unfortunately isn't reproducible right now. Maybe logging out and logging back in changed some type of state after the install, that's my best guess. Sorry that I don't have any further information.