Update: I've noticed that entities are saved (and available at the Datastore Viewer) when I save them using views (and the create_object function). But when I use shell (manage.py shell) to create and save new entity it isn't commited to the storage (but still can be seen in Tes.objects.all()).
I started playing with the django-nonrel with google appengine and I am getting frustrated by thing as simple as saving Entities.
I've set up my environment as described in instruction. I managed to run sample application and it runs ok. I'd like to extend it so it saves my entity to the storage. To do so:
I added new django module with models.py:
from django.db import models
class Tes(models.Model):
name = models.CharField(max_length=150)
I created a script to save some data:
import os
import sys
sys.path.append("d:\\workspace\\project\\")
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
from testmodule.models import Tes
t = Tes(name="test")
t.save()
tes = Tes.objects.all()
for t in tes:
print t.name
The script runs without errrors. When I run it few times one after another, it prints more and more "test" strings. But when I try running it after a minute break the Tes.objects.all() returns nothing. During that time the datastore file changes it size (but maybe that's just some kind of logs). When I look at the http://localhost:8000/_ah/admin/datastore I can select only AhAdminXrsfToken from select field.
Anyway, what am I missing? Where I can find some kind of logs which would tell me what's wrong?
This is a gotcha that causes a lot of confusion. From the djangoappengine docs:
Also, never run manage.py runserver together with other management
commands at the same time. The changes won't take effect. That's an
App Engine SDK limitation which might get fixed in a later release.
So you can't do manage.py runserver and manage.py shell at the same time. If you do, changes to the datastore in one will not be visible in the other. There's a lock on the local datastore enforced by the App Engine SDK. Make sure you have stopped the server before you start the shell.
Shoudn't it be t.put() if you are creating an entity rather than saving it? I use put() to create an entity and it works for me. And if you import django you may want to know that there are alternatives to django such as my choice GAE + Jinja2 + WTForms especially now that google.db.djangoforms is deprecated selecting a form framework for forms, a templating engine and perhaps a db framework and you do't have to import django which often results in forcing you to import much more than you need.
So my recommendation is to avoid import django... and instead use Jinja2 + WTForms. If you really want django on app engine then you might want to check in the project www.allbuttonspressed.com that enables all django for google app engine but be certain that you need this much django when I suspect all we need is a template engine and a form framework and we can do without django.
Related
Long story short, I need to call a python script from a Celery worker using subprocess. This script interacts with a REST API. I would like to avoid hard-coding the URLs and django reverse seems like a nice way to do that.
Is there a way to use reverse outside of Django while avoiding the following error?
django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.
I would prefer something with low-overhead.
As documented
If you’re using components of Django “standalone” – for example,
writing a Python script which loads some Django templates and renders
them, or uses the ORM to fetch some data – there’s one more step
you’ll need in addition to configuring settings.
After you’ve either set DJANGO_SETTINGS_MODULE or called configure(),
you’ll need to call django.setup() to load your settings and populate
Django’s application registry.
I am using a custom manager command to boot my django app from external scripts. It is like smashing a screw with a hammer, but the setup is fast and it takes care for pretty much everything.
I made an app(first app) with Django following a tutorial.
And I finally completed a web server with AWS EC2, nginx, uwsgi, mySQL, and Django.
Then I tried to make a new app(second app).
But I found that I put account information(user model) in first app's model.py. Furthermore, I added something like notification functions in first app's model and view etc...
I want to make new app with first app's account and notification, but I am not sure it's possible to split one app to two apps.
I'd like to make a site(project) have three apps which are account apps(including user model, notification, etc.), first app, and second app. Then, I thought second app can use user info like first app. (Is there any better way?)
I just have a questions, how can I split account app from first app without any data loss. Actually I afraid that if I make a problem, it's very hard to restore it. (model, view, url, ...)
My model is following
class Profile(models.Model) # I'd like to split into account app
class Recruit(models.Model) # stay in first app
class Apply(models.Model) # stay in first app
class Comment(models.Model) # stay in first app
I will appreciate if I can get some tips or references.
Thank you.
Create the new app
Move your models to them
Make migrations and fake migrate migrate --fake
Go to database and change the name of tables - Content types - permissions
for help use this one by me GITHUB script to change model names
Inform me if that worked well with you and don't expect it will be straight forward
Don't think about the app as isolated entity. The concept of the app is something that you want to distribute and let other developers reuse. This is not your case.
You refer the site as project and it's normal to have an app to import from another app. I would suggest you call them packages that are part of your projects, yes you add them in your INSTALLED_APPS but at the end are packages.
Try to have a good packages tree where the references are top-down and not crossed referenced.
Remember: you don't build the application for the database, you build it for the Domain, the database is just a Persistence implementation detail.
From this article.
This question already has an answer here:
Using django for CLI tool
(1 answer)
Closed 6 years ago.
I am exploring using django as an ORM and have a basic question, using eclipse, I was able to load django, create a project, setup my database connection in the settings.py file and run the
manage.py inspectdb
command which created successfully the models.py file so now i am left with the structure (familiar to all)
ProjectName
---ProjectName
------settings.py
------urls.py
------wsgi.py
---manage.py
---models.py
now the way i wish to use django is just a better way to interface with my database created in the models.py (and not as a webservice, or restful api, or anything like that)
when i try some simple code like:
import models
import django
django.setup()
my_model = models.SomeDefinedModel.objects.all()
for mod in my_model:
print mod
I get some exception:
django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.
All i want to do is query the table behind the database that the
SomeDefinedModel
is build from (using the inspectdb command)
is this possible? I've been searching on the internet forever, and cant seem to find a way to use this as an access layer.
Thanks -
This is extremely annoying to do. I have done it a few times and only for scripts that managed my data that is used in a django app for me. It feels really hacky and if all you want is the ORM, I wouldn't recommend using Django as this will load all this other stuff you don't need. If you just want an ORM, go with SQLAlchemy.
If that still didn't convince you, here is how I did it for a daemon:
What you have to do first is set an environment variable that tells django where to find your settings, then you have to tell django to set up. Then you can start using the Django stuff. After you do all of that, you can start importing your models.
Here is an example of how I did that:
import os
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "yourproject.settings")
import django
django.setup()
#Rest of your code
Again, if you aren't building a website or webapp, I heavily advise against using Django. This will make your application 100x bigger when you only want to use 1% of django. SQLAlchemy may even be a better ORM. I've been playing around with it more in the last couple of days and I feel like I can write more complex SQL. Link to SQLAlchemy: http://www.sqlalchemy.org/
django.forms is very nice, and does almost exactly what I want to do on my current project, but unfortunately, Google App Engine makes most of the rest of Django unusable, and so packing it along with the app seems kind of silly.
I've also discovered FormAlchemy, which is an SQLAlchemy analog to Django forms, and I intend to explore that fully, but it's relationship with SQLAlchemy suggests that it may also give me some trouble.
Is there any HTML Forms processing library for python that I haven't considered?
I've grown to love WTForms, it's simple, straightforward, and very flexible. It's part of my django-free web stack.
It's completely standalone, and carries over the good parts of django's form libraries, while imho having some things much better.
I'm not sure what you mean by "making most of the rest of Django unusable" and especially by "packing it along with the app". Are you familiar with the docs? If you just do as they suggest, i.e.
import os
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
from google.appengine.dist import use_library
use_library('django', '1.1')
don't django.forms and the rest of Django work for you (once you upload your app to Google)?
As the docs also explain,
Django versions 1.0 are later are not
included in the SDK. To test your app
with a newer version of Django on your
computer, you must download and
install Django from the Django
website.
but
You do not need to add the newer
Django library to your application
directory.
i.e. you don't have to "pack it along"; it's already made available on Google's servers by Google to your app engine application. (A few third-party apps that depend on relational features, admin especially, don't work -- but your own Django app, written using he App Engine data modeling libraries, will be fine!-).
You can also have a look at formencode, it is generic enough so that you may fit it in GAE.
Is there a more specific reason you don't want to use django.forms? I've quite successfully used bits and pieces of django all by themselves without trouble in several projects.
As an aside, there are several patches that make django sortof work in app-engine, though I assume you've considered and discarded them.
According to the documentation:
An app is a Web application that does
something -- e.g., a weblog system, a
database of public records or a simple
poll app. A project is a collection of
configuration and apps for a
particular Web site. A project can
contain multiple apps. An app can be
in multiple projects.
However, what are other examples of what makes an "app"?
What makes an app (for us) is one thing:
An App Is The Unit Of Reuse
If we might want to split it off to use somewhere else, it's an app.
If it has a reusable data model, it's an app. User Profiles: App. Customers: App. Customer Statistical History (this is hard to explain without providing too many details): App. Reporting: App. Actuarial Analysis: App. Vendor API's for data gathering: App.
If it is unique and will never be reused (i.e., customer specific) it's an app that depends on other apps. Data Loads are customer specific. Each is an app that builds on an existing pair of apps (Batch Uploads, and Statistical History)
Django apps are bundles of reusable functionality. When starting off it's easy to just use one custom app for your project, but the "Django way" is to break it up into separate apps that each only do one thing. You can take a look at django.contrib for examples of really well made reusable apps.
A recent example of mine: a client needed a way to import CSV data into the Django models. The easiest way would be to just add a model with a FileField and write a quick parser for the specific format of what they are uploading. That would work fine until the format changed and I had to go make the parser match. But this is a commonly repeated task (importing data) and unrelated to the existing app (managing that data) so I broke it out on its own. This pluggable app can import data for any active model. Now the next time a client needs import functionality I just add this code to installed_apps and run syncdb.
It's a judgement call when to break out an app onto its own, but the rule of thumb for me is if I'm likely to do something again I'll take the extra time to make it a generic app. That means I've created some tiny apps (some just contain a template tag), but it's little overhead for the future gains.
User management could very well be an app, if you are not going to use Django's built in user framework.
It has user interfaces and defined models for stored data, and it is really separate from the Blog or the Wiki application (although the information will be shared).
As long as both applications are in the same 'project' they should use the same settings for the DB. You should be able to by just making sure the proper models are imported where you are trying to use them.
See this link for a little more information.