According to Xeround's Release Notes they don't support save points and I can't figure out how to turn off support for this in Django 1.4. Does anyone know how to accomplish this?
I had the same problem. Django seems to only check the version of the MySql when it decides whether to use savepoints or not. Xeround probably uses some non-standard database-engine that doesn't support savepoints even if the MySql version is high enough.
Quick fix (just for testing) is to just edit the django/db/backends/mysql/base.py to override the logic:
Before:
self.features.uses_savepoints = self.get_server_version() >= (5, 0, 3)
After:
self.features.uses_savepoints = False
I tested this and it didn't seem to cause problems.
Note: Editing django sources directly like this is not recommended, you probably should just create your own db backend module by subclassing or copying the mysql module and placing it inside your project. Remember to update settings.py database configuration to point to your module.
Related
I just set up the environment for an existing Django project, on a new Mac. I know for certain there is nothing wrong with the code itself (just cloned the repo), but for some reason, Django can't seem to retrieve data from the database.
I know the correct tables and data is in the db.
I know the codebase is as it should be.
I can make queries using the Django shell.
Django doesn't throw any errors despite the data missing on the web page.
I realize that it's hard to debug this without further information, but I would really appreciate a finger pointing me to the right direction. I can't seem to find any useful logs.
EDIT:
I just realized the problem lies elsewhere. Unfortunately I can't delete this post with the bounty still open.
Without seeing any code, I can only suggest some general advice that might help you debug your problem. Please add a link to your repository if you can or some snippets of your database settings, the view which includes the database queries etc...
Debugging the view
The first thing I would recommend is using the python debugger inside the view which queries the database. If you've not used pdb before, it's a life saver which allows you to set breakpoints in your Python script and then interactively execute code inside the interpreter
>>> import pdb
>>> pdb.set_trace()
>>> # look at the results of your queries
If you are using the Django ORM, the QuerySet returned from the query should have all the data you expect.
If it doesn't then you need to look into your database configuration in settings.py.
If it does, then you must might not be returning that object to the template? Unlikely as you said the code was the same, but double check the objects you pass with your HttpResponse object.
Debugging the database settings
If you can query the database using the project settings inside settings.py from the django shell it sounds unlikley that there is a problem with this - but like everything double check.
You said that you've set up a new project on a mac. What is on a different operating system before? Maybe there is a problem with the paths now - to make your project platform independent remember to use the os.path.join() method when working with file paths.
And what about the username and password details....
Debugging the template
Maybe your template is referencing the wrong object variable name or object attribute.You mentioned that
Django doesn't throw any errors despite the data missing on the web
page.
This doesn't really tell us much - to quote the Django docs -
If you use a variable that doesn’t exist, the template system will
insert the value of the TEMPLATE_STRING_IF_INVALID setting, which is
set to '' (the empty string) by default.
So to check all the variables available to your template, you could use the debug template tag
{{ debug }}
Probably even better though is to use the django-debugging-toolbar - this will also let you examine the SQL queries your view is making.
Missing Modules
I would expect this to raise an exception if this were the problem, but have you checked that you have the psycopg module on your new machine?
We are considering migrating our dated django 1.3.1 app to the latest version (1.5.4).
I don't like migrations.
Are any specific problems to be thought of? Any show stoppers you may think of?
Of course I will study release notes and all this.
Will it be a real head ache or is it doable?
We have migrated our app from 1.4 to 1.5, we didn't fetch any issue which is blocker. We had needed to done couple of changes related to adminmedia, json library uses and url syntaxing in our html templates. They were some normal issues only.
But yes as you said its always better to check release notes before upgrading to latest version.
Hope this will help you.
Here are the few things you need to take care of:
Project directory structure has been changed.
Include ALLOWED_HOSTS in settings.py.
django.utils.simplejson is deprecated. import simplejson can be used instead.
Session data will not be saved, when the response code is 500.
django.forms.ModelMultipleChoiceField now returns an empty QuerySet as the empty value instead of an empty list.
Uploaded files are no longer created as executable by default. If you need them to be executable change FILE_UPLOAD_PERMISSIONS to your needs.
{% load adminmedia %} template tag can no longer be used.
If you’re using django.contrib.redirects, make sure INSTALLED_APPS contains django.contrib.sites.
I am working on a django website/project, it has already been internationalised/localised to us-english, gb-english and mandarin.
It is deployed with same codebase except for the settings config which states what lang to use. Some deployments are mandarin only, others are us-english.
The client now has a requirement to change some of the language used within a gb-english version for a specific deployment. My main goal is not to duplicate things and I think I can get what I need out of django 18n.
Basically, I am looking to find if i can or should use django i18n to handle:
'Welcome' on deployA
'Oh hai' on deployB,
even though they're still both gb-english based sites, I feel I should be able to say that deployA will use 'en_GB' and deployB would use 'en_GB_special'.
I suppose it's the fact that I want to use a non-standard i18n name/code that is making me wonder if I should do this, or if I am approaching this in the wrong manner.
I would only create a new language if you're intending to maintain two translations. If the new site will need to stay in sync with en_GB and/or you intend to use the customization in another language then I think you'd be better off creating new messages, adding a string for them to en_GB and add a flag to your application to switch the feature for your feline client.
I'm trying to integrate MongoDB with Django's Admin system (as per the Tumblelog tutorial on the mongodb site and hitting a bug when I try to python manage.py syncdb - it gives me this error - and I'm not entirely sure what to do about it. Thanks!
pymongo.errors.OperationFailure: command SON([('create', u'auth_permission'), ('max', False), ('capped', False), ('size', 0.0)]) failed: exception: create collection invalid size spec
```
Seems there is a problem with permission app, Try to add djangotoolbox to you settings.py.
The nature of NoSQL is not compatible with django ORM neither with auth, permission apps which they depends on JOINS to working together.
Anyway, Have you met django-nonrel ? django-nonrel provides more apps and solutions to work with MongoDB and other NoSQL datastores.
See this link: https://github.com/django-nonrel/mongodb-engine/pull/134
The main issue is that for collections that have an uncapped size, set a large capped size instead of so that the subsequent command does not fail.
I'm assuming you're on django-nonrel 1.3.1. I forked off of django-nonrel/mongodb-engine and have the fix in https://github.com/statguyjames/mongodb-engine.git#master.
First I tried statguy's solution by replacing sql_create_model() method entirely - but it didn't work, some errors kept appearing.
Then what I did was that I added
size = getattr(model._meta, 'collection_size', None)
if size is not None:
kwargs['size'] = size
else:
kwargs['size'] = 10000000000
right after
for option, mongo_option in [
('capped', 'capped'),
('collection_size', 'size'),
('collection_max', 'max')
]:
kwargs[mongo_option] = getattr(model._meta, option, False)
in file creation.py from django_mongodb_engine.
This way the error wasn't appearing anymore. However, due to that immense value, mongo will allocate some files on disk that have basically turned my current database from a few MB to about 17GB - ending in an error to allocate new file.
So careful about enforcing a value. I might be missing something, though.
So I'm working on a website where there are a couple important values that get used in various places throughout the site. For example, certain important dates, like the start and end dates for registration.
One way I can do this is making a model that stores these values, but that sounds like overkill (since I'd only have one instance). Another way is to store these values in the settings.py file, but if I wanted to change them, it seems like I would need to restart the webserver for them to take effect. I was wondering what would be the best practice in Django to handle this kind of stuff.
You can store them in settings.py. While there is nothing wrong with this (you can even organize your settings into multiple different files, if you have to many custom settings), you're right that you cannot change these at runtime.
We were solving the same problem where I work and came up with a simple app called django-constance (you can get it from github at https://github.com/comoga/django-constance). What this lets is store your settings in a settings.py, but once you need to turn them into settings configurable at runtime, you can switch to a Redis data store with django admin frontend. You can even use the value from settings as your default. I suggest you try this app out.
The changes to your code are pretty minimal, as pasted from docs you initialize your dynamic settings like this:
CONSTANCE_CONFIG = {
'MY_SETTINGS_KEY': (42, 'the answer to everything'),
}
And then instead of importing settings from django conf, you do this:
from constance import config
if config.MY_SETTINGS_KEY == 42:
answer_the_question()
If you want a specific set of variables available to all of your template, what you are looking for is Context Processors.
http://docs.djangoproject.com/en/dev/ref/templates/api/#writing-your-own-context-processors
More links
http://www.b-list.org/weblog/2006/jun/14/django-tips-template-context-processors/
http://blog.madpython.com/2010/04/07/django-context-processors-best-practice/
The code for your context processors, can live anywhere in your project. You just have to add it to your settings.py under:
TEMPLATE_CONTEXT_PROCESSORS =
You could keep the define your constants in your settings.py or even under a constants.py and just
from constants import *
However as you mentioned, you would need to reload your server each time the settings are updated. I think you first need to figure out how often will you be changing these settings? Is it worth the extra effort to be able to reload the settings automatically?
If you wanted to automatically enable the settings, each time they are updated you could do the following:
Store settings in the DB
Upon save/change, write output to a file
settings.py / constants.py reads files
reload server
In addition, you have a look at the mezzanine project which allows you to update settings from the django admin interface and will reload as well.
See: http://mezzanine.jupo.org/docs/configuration.html
If the variables you need will be updated infrequently, i suggest just store them in settings.py and add a custom context processor.
If you are using source control such as GIT, updating will be quite easy, you can just update the file and push to your server. For really simple reloading of the server you could also create a post-recieve hook for git that will automatically reload the server when new code is pushed.
I would only suggest the other option if you are updating settings fairly regularly.