Building our Django project, when updating the production site, we got this error on the log: Error was: ‘str’ object has no attribute ‘_default_manager’

I was puzzled because on the others sites with the same exact code (using git here), the project worked flawless. We tried using fresh databases, desactivating the django’s admin site, etc.

The problem got solved when I deleted some *.pyc from two of he apps used, specially the one used for the authenticaion. So…remember: If you get some strange error, try deleting those *.pyc!

PD: The error happened again. This time, I got solved it by entering this code before admin.autodiscover() from the main urls.py:

from django.db.models.loading import cache as model_cache
if not model_cache.loaded:
    model_cache.get_models()

I got the solution from here: http://code.djangoproject.com/ticket/10405#comment:10

It’s just a workaround. Hope it works for you!

Anuncios

South:
South es una aplicación de Django que facilita/automatiza enormemente las migraciones de base de datos, en aquellos casos en los que modificamos el modelo de django, y queremos conservar los datos existentes.

Funciona por aplicación, es decir, para cada aplicación enganchada a nuestro proyecto, South generará los datos necesarios para la migración de la misma. Los comandos a utilizar se utilizan desdel el mismo ámbito de manage.py de nuestro proyecto, así, por ej.: > python manage.py convert_to_south;  sería la manera de usar un comando de south.

El primer paso a realizar es decidir si es una aplicación nueva con respecto a la información contenida en la base de datos, o bien queremos preparar south para datos ya existentes.

-1er caso: Hemos creado una nueva aplicación que incluye nuevos modelos:
> manage.py schemamigration <nombre_app> –initial; el cual crea el primer esquema de la base de datos, normalmente estando compuesto el mismo por las sentencias necesarias para crear la base de datos desde 0 usando SQL.

> manage.py migrate <nombre_app>; para realizar la primera migración punto_0, a partir de la cual, south puede generar el resto de migraciones.

-2º caso: Queremos utilizar una base de datos basada en modelos ya definidos:
> manage.py convert_to_south <nombre_app>; el cual tiene en cuenta lo que ya hubiera definido, y prepara a south para poder trabajar con los    datos existentes. Este proceso define un schema inicial, entonces crea y lleva a cabo una migración falsa (migración punto_0.

A partir de aquí, se repite un ciclo consistente en crear un nuevo esquema y luego migrar la información de la base de datos. Esto es:
> manage.py schemamigration <nombre_app> –auto
> manage.py migrate <nombre_app>

Avanzado:
Modelos con campos personalizados pero simples:
South incluye una lógica para poder entender los modelos de Django y realizar migraciones. Sin embargo, cuando usamos tipos de campos para columnas en la base de datos que South no conoce explícitamente, debemos indicarle cómo debe tratarlos.

Un campo simple es aquel que hereda de otro controlado por south (normalmente un campo ya definido por Django), que no añade una transacción en la base de datos distinta. Simplemente le decimos a south que lo trate como el campo padre.

Para esto, primero importamos lo siguiente de South:
> from south.modelsinspector import add_introspection_rules

Luego utilizamos dicha sentencia para incluir nuestro campo personalizado. El mejor lugar para incluirla sería justo después de la definición de dicho campo, normalmente un fichero llamado fields.py:

class SerializedDataField(models.TextField):

add_introspection_rules([], [“^proyect\.app\.fields\.SerializedDataField”])

Empezando con esto. Trabajando tan pronto tenga un poco más de tiempo. Este espero que sea un blog tanto en español como en inglés.

Just starting with this, building it up as soon I have some time. Both in english & spanish flavours.