Si usted está tratando de mover una aplicación de legado a Django, estoy de acuerdo con @chrisdpratt y usted debe tratar de convertir sus clases de modelos de Django. Se requerirá un gran esfuerzo, para que cuando esté listo, se puede seguir esta ruta:
crear una aplicación legacy y poner su código heredado allí.
Si decide que su código no es tan importante, y solo desea tomar los datos, y está almacenado en un servidor basado en SQL, puede intentar usar "modelos heredados" que leerán sus datos desde tu servidor heredado Sugiero configurar una segunda conexión de BD llamada "legacy" para esto. ver: https://docs.djangoproject.com/en/dev/topics/db/multi-db/
crear una secuencia de prueba de línea de comandos para asegurarse de que puede cargar sus clases heredadas de la base de datos. (Asegúrese de establecer/exportar la variable de entorno DJANGO_SETTINGS_MODULE desde el intérprete de comandos del shell para ejecutar scripts desde la línea de comandos o vea https://docs.djangoproject.com/en/dev/ref/django-admin/?from=olddocs#running-management-commands-from-your-code).
Crear sus nuevos modelos de Django en una nueva aplicación ("myapp").
Opcionalmente, se puede utilizar inspectdb de nuevo para obtener un modelos básicos de forma automática a partir de una base de datos. Sin embargo, asegúrese de cambiar el nombre de los modelos al aspecto y tacto estándar de Django y eliminar los campos y atributos innecesarios.
Crea una secuencia de comandos que lee los datos heredados y los escribe en los nuevos modelos.
Migre la lógica requerida de las clases antiguas a las nuevas.
Usted puede utilizar esto como un esqueleto para la secuencia de comandos para el paso 3:
# legacy/management/commands/importlegacydb.py
from django.core.management.base import NoArgsCommand
import myapp.models as M
import legacy.models as L
import sys
write = sys.stdout.write
def copy_fields(old, new, mapping):
for old_key, new_key in mapping.items():
value = getattr(old, old_key)
if type(value) is str:
value = value.strip()
if type(new_key) is tuple:
value = new_key[0](value)
new_key = new_key[1]
else:
if new_key == "name":
value = value[0].upper() + value[1:]
setattr(new, new_key, value)
def import_table(old_class, new_class, mapping):
write("importing %s " % old_class.__name__)
lookup = {}
l = old_class.objects.all()
for old in l:
new = new_class()
copy_fields(old, new, mapping)
new.save()
lookup[old.id] = new.id
write (".")
print " Done."
return lookup
class Command(NoArgsCommand):
help = "Import data from legacy db."
def handle_noargs(self, **options):
"""
Read data from legacy db to new db.
"""
print "Importing legacy data"
import_table(L.X, M.X, { 'old_field' : 'new_field', 'old_field2' : 'new_field2'})
import_table(L.Y, M.Y, { 'old_field' : 'new_field'})
print "Done."
Si el almacenamiento de datos serializados en una base de datos es la respuesta, por lo general, usted está haciendo la pregunta equivocada. ;) Eso es una mala práctica y debe evitarse si es posible. Dicho esto, realmente no entiendo lo que estás tratando de hacer. ¿Estas clases directas de python estás tratando de integrarlas en tu proyecto Django? –
Sí, son clases de Python. La documentación de Django [link] https://docs.djangoproject.com/en/dev/howto/custom-model-fields/ [/ link] sugiere usar un campo de modelo personalizado para almacenar y recuperar objetos de Python de la base de datos.Mi pregunta es qué se considera la mejor práctica en el dominio de Django de tomar una clase de Python (generada a partir de un diagrama de clase de modelo UML) e integrar esa clase con las clases de modelo para persistencia alrededor de esas clases. P.ej. poner toda su metodología en la clase de modelo de Django podría ser de una sola manera, pero ¿cuál es la mejor práctica? – Michael
Bueno, la mejor práctica, en mi opinión, sería traducir la funcionalidad a Django. A falta de eso, la serialización puede ser su única opción, pero un atajo ahora, probablemente genere más dolor en el futuro. –