Cómo almacenar un diccionario en un modelo Django?

Si no necesita consultar ninguno de estos datos adicionales, puede almacenarlos como un diccionario serializado. Use repr para convertir el diccionario en una cadena, y eval para volver a convertir la cadena en un diccionario. Tenga cuidado con eval de que no haya datos de usuario en el diccionario, o use una implementación safe_eval.

Llegué a este post por el resultado 4rth de Google a"django store object"

Un poco tarde, pero django-picklefield me parece una buena solución.

Ejemplo de doc:

Para usar, simplemente defina un campo en su modelo:

>>> from picklefield.fields import PickledObjectField
>>> class SomeObject(models.Model):
>>>     args = PickledObjectField()

Y asigna lo que quieras (siempre y cuando sea seleccionable) al campo:

>>> obj = SomeObject()
>>> obj.args = ['fancy', {'objects': 'inside'}]
>>> obj.save()

Otra solución limpia y rápida se puede encontrar aquí: https://github.com/bradjasper/django-jsonfield

Por conveniencia copié las sencillas instrucciones.

Instalar

pip install jsonfield

Uso

from django.db import models
from jsonfield import JSONField

class MyModel(models.Model):
    json = JSONField()

Como Ned respondió, no podrá consultar "algunos datos" si utiliza el enfoque de diccionario.

Si todavía necesita almacenar diccionarios, entonces el mejor enfoque, de lejos, es la clase PickleField documentada en el nuevo libro de Marty Alchin Pro Django. Este método utiliza las propiedades de clase de Python para pickle / desempaquetar un objeto de Python, solo bajo demanda, que se almacena en un campo de modelo.

Lo básico de este enfoque es usar el contibute_to_class método para agregar dinámicamente un nuevo campo a su modelo y utiliza getattr / setattr para hacer la serialización bajo demanda.

Uno de los pocos ejemplos en línea que pude encontrar que es similar es esta definición de un JSONField.

No estoy seguro exactamente de la naturaleza del problema que está tratando de resolver, pero suena curiosamente similar a BigTable Expando de Google App Engine.

Los Expandos permiten especificar y almacenar campos adicionales en una instancia de objeto respaldada por una base de datos en tiempo de ejecución. Para citar los documentos:

import datetime
from google.appengine.ext import db

class Song(db.Expando):
  title = db.StringProperty()

crazy = Song(title='Crazy like a diamond',
             author='Lucy Sky',
             publish_date='yesterday',
             rating=5.0)

crazy.last_minute_note=db.Text('Get a train to the station.')

Google App Engine actualmente soporta Python y el framework Django. Podría valer la pena investigar si esta es la mejor manera de expresar su modelo.

Los modelos de bases de datos relacionales tradicionales no tienen este tipo de flexibilidad de adición de columnas. Si sus tipos de datos son lo suficientemente simples, podría romper con la filosofía tradicional de RDBMS y hackear valores en una sola columna a través de la serialización como @Ned Batchelder propone; sin embargo, si tiene para usar un RDBMS, la herencia del modelo Django es probablemente el camino a seguir. Notably, it will create a one-to-one foreign key relation for each level of derivation.

Estoy de acuerdo en que debe abstenerse de rellenar datos estructurados de otra manera en una sola columna. Pero si tienes que hacer eso, Django tiene un build-in XMLField.

También hay JSONField en los fragmentos de Django.

Ser "no igual a todas las instancias del modelo" me suena como una buena combinación para una "base de datos libre de esquemas". CouchDB es el hijo póster de ese enfoque y podrías considerarlo.

En un proyecto moví varias mesas que nunca jugaron muy bien con el Django OR a CouchDB y estoy bastante contento con eso. Utilizo couchdb-python sin ninguno de los módulos CouchDB específicos de Django. Una descripción del modelo de datos se puede encontrar aquí. El el movimiento de cinco " modelos "en Django a 3" modelos "en Django y una" base de datos " CouchDB realmente redujo ligeramente las líneas totales de código en mi aplicación.

Piénsalo y encuentra los puntos en común de cada conjunto de datos... luego define tu modelo. Puede requerir el uso de subclases o no. Las claves foráneas que representan puntos en común no deben evitarse, sino alentarse cuando tienen sentido.

Rellenar datos aleatorios en una tabla SQL no es inteligente, a menos que sean datos verdaderamente no relacionales. Si ese es el caso, defina su problema y tal vez podamos ayudarlo.

Django-Geo incluye un "DictionaryField" que podría ser útil:

Http://code.google.com/p/django-geo/source/browse/trunk/fields.py?r=13#49

En general, si no necesita realizar consultas a través de los datos, use un enfoque desnormalizado para evitar consultas adicionales. La configuración del usuario es un buen ejemplo!

Si está utilizando Postgres, puede usar un campo hstore: https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/fields/#hstorefield .

Esta pregunta es antigua, pero yo estaba teniendo el mismo problema, terminó aquí y la respuesta elegida ya no podía resolver mi problema.

Si desea almacenar diccionarios en Django o REST Api, ya sea para ser utilizados como objetos en su front end, o porque sus datos no necesariamente tendrán la misma estructura, la solución que utilicé puede ayudarlo.

Al guardar los datos en su API, use json.dump () método para poder almacenarlo en un formato json adecuado, como se describe en este pregunta.

Si utiliza esta estructura, sus datos ya estarán en el formato json apropiado para ser llamados en el front end con JSON.parse () en tu llamada ajax (o lo que sea).