Integrating Django tutorial example Polls app and django-registration - django

I'm learning Django on Ubuntu 13.04, Python 2.7, Django 1.5, Postgres 9.2,
Bootstrap 3.0. I'd like to achieve a combination of the tutorial example Polls app with django-authentication.
As my first effort I got the Polls app working from the Django 1.5 tutorial. I then installed django-registration 1.0 and these templates to make it work. I chose that package for authentication as opposed to django-allauth as a result of my question on authentication framework.
Now I want to integrate Polls and django-registration to record a set of results per user. After the poll results have been collected the admininstrator uses Django Admin interface to run a script to analyse the results (e.g. compute some statistics) and send an email to a subset of all users.
I briefly looked at two existing projects that looked like could get me there out of the box.
Light Bird's Questionnaire App was too complicated using a custom library of modular class based views. I'd like to keep it as simple as possible, using as much of out-of-the-box Django 1.5 functionality as possible for ease of maintenance and initial design.
Pinax web framework on top of Django, although a great idea, seems to be stuck in dark ages of 2011 with latest code supporting only Django 1.4 and Bootstrap 2.x. Starter projects don't look that useful and documentation isn't flash either.
Based on the above it looks like I'll have to do the integration of Polls and registration manually. At first pass I was thinking roughly the following:
The poll & choice could be simplified down to just a numeric answer to a question.
At database level we would need a separate table.
The primary key would be the userid.
Each column would store one answer per.
I'm guessing this would need a class PollsResults in model.py that would include defining the primary key as User, which should exist via django-registration.
Exactly how to do that and what follows gets a bit hazy to me at the moment.
I'm sure the above is a simple exercise for a Django developer. Could anyone give me some starting hints or even better an existing project that does something similar?

It looks like you're slightly underestimating the power of using a framework such as django. For example, you don't really need to worry too much about tables in the database or what will be their primary keys, because django's Object Relational Mapper (ORM) takes care of a lot of that for you.
If you want to connect two models (database tables) in django you can use a foreignkey like this:
class ThingOne(models.Model):
name = models.CharField(max_length=50)
class ThingTwo(models.Model):
thing_one = models.ForeignKey('ThingOne')
The quotes around 'ThingOne' in my ForeignKey are actually unnecessary because the ThingOne model has already been defined, but I like to use quotes anyway because it means your ForeignKeys will also work for models defined below (in your code) the model linking to them.
You therefore just need to add a relationship between your Polls and User models. If one user might have many poll results you should probably use a ManyToManyField instead of a ForeignKey but the principle is the same. That should be enough to get you started.

Related

How to setup rethinkdb with django?

I have followed various posts and tutorials but couldn't find anything that is relevant. I found a ORM for rethinkdb "https://github.com/dparlevliet/rwrapper" but don't know how to use it?
I am new to to django and python.
It depends on what you want to do.
There is no way to simple replacement of Django's ORM with RethinkDB now. However, working with RethinkDB driver is simple enough, and similar to how you would use Django ORM.
The nearest thing is indeed rwrapper, you can try starting with this tutorial.
If you don't need to use Model classes, then you just need to find a place to connect to database (or use some sort of Singleton or Factory to connect to the database), and then just import rethinkdb as r and r.connect() and then just write queries with ReQL.
If you need realtime data, then Django is not suitable for that at all. You can consider mixing Django with Tornado
Django doesn't support RethinkDB at the moment and I don't think there's any plan for it as well.
Django developers don't add new stuff to the code base just because it's something new and might be cool. It should be really well mature and a high needs for it. So, I don't think you'll be hearing anything about RethinkDB from Django devs anytime soon.
This project might be something interesting:
https://github.com/thejsj/django-and-rethinkdb
In order to use any database with Django, the adapter should completely be a Django DB Backend in order to work with:
Models
Admin
Forms
Various Class Based Forms
Session
Auth
etc...
In others words, as long as the db backend doesn't support all the django database operations is not something that you wanna use.

Django nonrel Models

I have been looking at the documentation on django nonrel but think i have confused my self.
I have a project using the setup instructions found at http://www.allbuttonspressed.com/projects/djangoappengine#installation and continued to setup a django application. I am making a simple news feed. Now it has come to create the models but there appears to be two ways of doing this, using models.Model or db.Model.
models.Model is the django way of doing it, and if I create a model using this it appears to use nosql, this also allows me use of the built in admin.
db.Models is the non-rel way of doing things. If I create the model using this is appears to use nosql again but this method does not let me make use of the django admin. I thought the point of django non-rel was to let me make use of the admin and a majority of the default functionality in django.
I would also like to ask what is the difference between django non-rel and pure django on app engine and how does this affect how the models are created?
This is incorrect:
db.Models is the non-rel way of doing things
Where did you get this idea? db.Models is the AppEngine way of doing things. django-nonrel allows you to use the Django way even though you're on AppEngine. As you say, the point of django-nonrel is to allow you to use the admin etc, for which you need to do things the Django way, ie models.Model.

CodeIgniter & Datamapper as frontend, Django Admin as backend, database tables inconsistent

I created a database for a site i'm doing using Django as the admin backend. However because the server where the site is hosted on, won't be able to support Python, I find myself needing to do the front end in PHP and as such i've decided to use CodeIgniter along with Datamapper to map the models/relationship.
However DataMapper requires the tables to be in a specific format for it to work, and Django maps its tables differently, using the App name as the prefix in the table. I've tried using the prefix & join_prefix vars in datamapper but still doesn't map them correctly.
Has anyone used a combination of this? and if so how have the fixed the issue of db table names being inconsistent? Is there anything out there that i can use to make them work together?
----edit: clarification on backend---
Let me clarify: i'm going to be running the admin from a subdomain pointing to a python ready server. However i can't move the main domain name from the php only webserver because of certain constraints/binding contracts the company got itself in. and don't want to use cloaking/masking because of seo purposes.
i'm using the django admin because i'm using some packages to make a pretty/functional admin, such as grappelli for the admin template, along with its editor for editing news stories, etc. also using photologue to manage photos/galleries. etc.
If your problem is simply making Django use the same tables as your other software, use the db_column and db_table parameters in the models.
http://www.djangoproject.com/documentation/models/custom_columns/
Two apparent solutions:
Instead of hacking one or both to work well with each other, emulate the Django admin in PHP/CodeIgniter code. **
Get a server that supports Django. Make the frontend in Django.
Time-wise, either one of those solutions will be less involving than trying to make two different frameworks using different programming languages mesh well together. I can't imagine the future maintenance required to ensure everlasting compatibility and interoperability.
Also, I assume by saying:
I created a database for a site i'm doing using Django as the admin backend
You really mean that you modeled your apps using Django, and that you also intend on administrating the database that has resulted from this modeling in the Django admin. (In which case you already have your Models layer complete and should just try building the rest of the site in Django)
If that's the case then in your models you are going to need to define the exact column names (db_column) that DataMapper will expect, as well as manually define the table names (db_table), including M2M tables.
You may also have to define all of your primary keys manually, if DM expects something named differently.
Also:
If the server can't support Python, where are you going to be running your backend? Different server? Locally? This plan just isn't making a lot of sense.
** I would not suggest trying this. I had been attempting to make a CI backend that actually shared much of the same ideas as Django's admin, before I knew about Django's admin. And of course once discovering Django, I dropped the CI work immediately and continued on with what I have found to be a much more amazing framework that is much faster to develop on.
So as I understand you plan on using Django just because of django-admin, and you are trying to use CI for the actual site because the server runs PHP, right?
So why don't you use framework that generates something like Django's admin but that you can run on your server?
The Symfony Framework has a really nice admin generator, in the spirit of Django's and you might be able to run it on your server. This would save you from the maintainance nightmare that might come later as #jonwd7 answered

Django pluggable for managing currency accounts and transactions

We are writing an application that requires users to have accounts with balances in dollars and points. Is there a pluggable django app already out there that will help us?
There is an app called python-money. It has some code to define a MoneyField in Django models, but our initial experiments with it showed some problems so we just switched to using regular DecimalField.
DecimalField is intended for currencies and I think this is best for your case as well because it doesn't sound like you need to maintain balances in multiple currencies.
Edit: Responding to additional requirements where transactions, account management etc. are needed.
Try minibooks, especially taking notice of their Ledger models.
If this doesn't work I think you'll have to step outside of Django and try to incorporate something like OpenERP or Tryton (an OpenERP fork) into your Django app.

How to port from Drupal to Django?

What would be the best way to port an existing Drupal site to a Django application?
I have around 500 pages (mostly books module) and around 50 blog posts. I'm not using any 3rd party modules.
I would like to keep the current URLS (for SEO purposes) and migrate database to Django. I will create a simple blog application, so migrating blog posts should be ok. What would be the best way to serve 500+ pages with Django? I would like to use Admin to edit/add new pages.
All Django development is similar, and yours will fit the pattern.
Define the Django model for your books and blog posts.
Unit test that model using Django's built-in testing capabilities.
Write some small utilities to load your legacy data into Django. At this point, you'll realize that your Django model isn't perfect. Good. Fix it. Fix the tests. Redo the loads.
Configure the default admin interface to your model. At this point, you'll spend time tweaking the admin interface. You'll realize your data model is wrong. Which is a good thing. Fix your model. Fix your tests. Fix your loads.
Now that your data is correct, you can create templates from your legacy pages.
Create URL mappings and view functions to populate the templates from the data model.
Take the time to get the data model right. It really matters, because everything else is very simple if your data model is solid.
It may be possible to write Django models which work with the legacy database (I've done this in the past; see docs on manage.py inspectdb).
However, I'd follow advice above and design a clean database using Django conventions, and then migrate the data over. I usually write migration scripts which write to the new database through Django and read the old one using the raw Python DB APIs (while it is possible to tie Django to multiple databases simultaneously, too).
I also suggest taking a look at the available blogging apps for Django. If the one included in Pinax suits your need, go ahead and use Pinax as a starting point.
S.Lott answer is still valid after years, I try to complete the analysis with the tools and format to do the job.
There are many Drupal export tools out of there by now but with the very same request I go for Views Datasource choosing JSON as format. This module is very solid and available for the last version of Drupal. The JSON format is very fast in both parsing and encoding and it's easy to read and very Python-friendly (import json).
Using Views Datasource you can create a node view sorted by node id (nid), show a limited number of elements per page, configure a view path, add to it a filter identifier and pass to it the nid to read all elements until you get an empty JSON response.
When importing in Django you have a wide set of tools as well, starting from loaddata to load fixtures. Views Datasource exported JSON but it's not formatted as Django expects fixtures: you can write a custom admin command to do the import, where you can have the full control of the import flow.
You can start your command passing a nid=0 as argument and then let the procedure read, import and then fetch data from the next page passing simply the last nid read in the previous HTTP request. You can even restrict access to the path on view but you need additional configuration on the import side.
Regarding performance, just for example I parsed and imported 15.000+ nodes in less than 10 minutes via a Django 1.8 custom admin command on an 8 core / 8 GB Linux virtual machine and PostgreSQL as DBMS, logging success and error information into a custom model for each node.
These are the basics for import/export between these two platform, for detailed information I described all the major steps for export from Drupal and then import to Django in this guide.