I am making some tests on a development site, currently using Django 1.4.
Most Django users are aware that Django 1.5 brings more flexibility in User models.
The project I'm working on uses monkey-patching on the auth.User model, and it works well. This adds useful methods I use everytime.
I have not added any database field on the User model for the sake of compatibility, my code only involves this:
User.__bases__ += (UserPlus,)
User.__unicode__ = UserPlus.__unicode__
UserPlusManager().contribute_to_class(User, 'objects')
with UserPlusManager being a subclass of UserManager.
Now, imagine I want to switch to the new user model. I already have many apps in INSTALLED_APPS, some of them are on unmaintained repos and have models with fields tied to auth.User.
I don't see a ny obvious strategy for this kind of configuration.
So, is it really advisable to upgrade to Django 1.5 with this in mind ? If so, what steps should I take ?
If a construct in Django changes, any third-party apps that leverage that construct would have to react accordingly. If your project is dependent on third-party apps that aren't 1.5 compatible, you should wait to upgrade your project until they are.
Related
I'm running into the following issue:
I have an older (recently upgraded to Django 1.6) site that uses one-to-one relations for user profiles, but the FK references to certain models are pointing to auth.User. I'm building a site in 1.8 on a separate subdomain that uses the same database with the old one and uses two apps from the old one but has a custom auth model class. I know what I'm doing and want different tables for the users of both sites. But the system check for the new site fails with the fields.E301 error:
core.RecipientAccount.created_by: (fields.E301) Field defines a relation with the model 'auth.User', which has been swapped out.
HINT: Update the relation to point at 'settings.AUTH_USER_MODEL'.
Is it possible to work around this? Or will I simply have to use 1.6 for the new site or write lots of custom migrations to refactor the old one?
I've found a solution to the problem for the time being. Ultimately I'd refactor the old project to use a custom user model of it's own. But a temporary fix is using a subclass of ForeignKey to reference django.contrib.auth.User which skips the check for swapped model.
class ForeignKeySkipsSwappedCheck(models.ForeignKey):
def check(self, **kwargs):
from django.db.models.fields.related import RelatedField
errors = super(RelatedField, self).check(**kwargs)
errors.extend(self._check_related_name_is_valid())
errors.extend(self._check_relation_model_exists())
errors.extend(self._check_clashes())
return errors
I have a huge... challenge in front of me. For about a week or two I've been migrating 1.5.5 django project to 1.7.1. A huge jump, many deprecated variables, methods and so on.
In 1.5.5 there were some south migrations done but not everywhere, as it was not implemented from the beginning. So let's say there are no migrations, they have to be created.
Also there is a wish to add a cms to the already upgraded project, but with django-cms-3.0.7 I constantly encounter some issues with migrations, south existing etc.
Is there a CMS that I can use with this app that won't be bothered by migrations and django version?
All I want to edit is the static content (text, images, maybe adding videos) before user logon. No integration with models. Just some info pages.
Any suggestions?
A maybe oversimplified solution for this could be django-front. Create your static pages and add the fields you want to edit. You edit it with a wysiwyg editor. I use it for my terms of service/privacy policy.
You will probably be always bothered by migrations and django version when using an app that brings extra functionality, but the apps should not be hard to upgrade and normally they have a warning/walk through when an important change on their arquitecture/functionality has happened.
That being said, i don't think migrations change dramatically now. The change to include them in the django project was an important (and needed) one.
If you want something even more simple (and time resistant) just create a model for your pages and render it on your template:
class Content(models.Model):
html_content = models.TextField()
image_content = models.ImageField()
Register that model to your admin and that should do the trick. For simple applications this may be enough.
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.
I want to add Django Sessions to my Django Admin, and I am following an SO post about this, but it is unclear where I store this code. Do I put it in an admin.py file? Under what directory?
In short, it doesn't matter. You can put the code into any of your apps' admin.py files. However, in situations like these I tend to use a generic app in my project, usually named something like utils, that exists for the sole purpose of housing code that doesn't belong to one specific app or could be used by multiple apps.
If you want to be more specific, you can create a sessions app in your project specifically devoted to this code and any other code related to session management for your project, or perhaps an existing app that is somewhat related. For example, I put customizations to the User admin in my accounts app that holds the UserProfile model.
I will be brief: to work in the spirit and idea of a Django app, it is ok for an app to import models from inside another app ? Say, a User statistics app will import models from a User app something like: from users.models import users
The answer is yes. It's perfectly okay for one application inside your django project to import models from another application. The power of a django project lies in the apps and their interactions.
Also make sure that you have utility applications importing models from more generic applications and not the other way. So "userstatistics" app should import models from the "users" app but "users" app should not rely on the "userstatistics".
If your app is importing models from a 3rd party application (lets say django-piston), be sure to specify that in a requirements file.
If you're building an internal app that has no chance of ever being released to the public, sure, do whatever you want.
If you're building an internal app that has little chance of ever being released to the public, but will possibly be used by future/current developers, sure, but be sure to document what the app needs to work properly.
If you're building an app for public release, try to keep it self-dependent (and django-internals dependent, ie, use what django provides, when possible). If you really need a third-party app to work, or if a third party app would make your code more manageable, then sure, include dependencies, but be doubly sure to document all requirements and necessary setup.
In most cases, you can do almost whatever you want so long as you have sufficient documentation.
I do, however, have to question the sanity of making your own User model that has the same name as django's builtin auth.User.
You cand try better extending the Django User model with inheritance. You will use the django user with custom field added, so you will have the same user for all the apps.
You can directly import models in app2/models.py. Usually you might need a foreign key, which looks like
models.ForeignKey('app1.ModelClass1', on_delete=models.CASCADE, related_name='modelclass2')
Don't do this. They will have the same app name and the ORM will be confused. Use an abstract model instead, and have both derive from it.