Sí, yo al final entendí también que des de django consideran esta la forma correcta. Para mi tiene sentido. En cualquier caso, me lo dejé documentado para mi yo futuro y por si le interesara a alguien :P https://self.paudirac.com/blog/legacy-databases-in-django/
¡Gracias!, ----- Pau Python..., what else? On Mon, May 9, 2022 at 1:38 PM Juan Ignacio <euriba...@gmail.com> wrote: > Tengo el mismo problema y, por lo que he podido ver, no hay forma facil > de resolverlo. Yo por el momento tengo una receta en un Makefile para > migrar, donde especifico para cada app, la base de datos a usar. Los > routers no se usan, como tu dices, en estos casos. Ademas, por lo que vi en > su dia, los de Django insisten en que esta es la manera correcta y no > tienen planes de cambiarlo. > > On Fri, 6 May 2022 at 12:14, Pau Cervera <pau.cerv...@gmail.com> wrote: > >> Buenas, >> >> Tengo una duda sobre cómo maneja Django las migraciones con múltiples >> bases de datos.En mi caso tengo dos DATABASES en el settings >> >> DATABASES = { >> 'default': { >> 'ENGINE': 'django.db.backends.mysql', >> 'NAME': 'producto', >> }, >> 'legacy': { >> 'ENGINE': 'django.db.backends.mysql', >> 'NAME': 'legacy-schema', >> } >> } >> >> la DB default está manejada por django desde siempre y la legacy tiene >> modelos generados vía inspecdb en una django application que también se >> llama legacy. En un principio la BD legacy era de sólo lectura, con lo que >> tener los modelos con managed = False (cómo los genera inspectdb) ya estaba >> bien. >> >> Con este sistema, y aunque el managed = False, django genera entradas en >> la tabla django_migrations para legacy (pués está instalada) aunque no >> genera tablas (el comando sqlmigrate sale con SQL vacío), cosa que está >> bien porqué están en otra BD. >> >> El problema que tengo ahora es que quiero empezar a gestionar los modelos >> de legacy des de Django. Esto supone cambiar los managed = False por >> managed = True y a partir de ahí cambiar los modelos. Por ejemplo, añadir >> una columna a una tabla. >> >> A priori esto genera una migración de cambio de metadatos de managed = >> False a managed = True y después una migración normal que añade la columna >> al schema. >> >> Para gestionar a qué BD pertenecen las tablas tengo un custom database >> router cómo este: >> >> class LegacyRouter: >> route_app_labels = {'legacy',} >> legacy_database = 'legacy' >> >> def db_for_read(self, model, **hints): >> if model._meta.app_label in self.route_app_labels: >> return self.legacy_database >> return None >> >> def db_for_write(self, model, **hints): >> if model._meta.app_label in self.route_app_labels: >> return self.legacy_database >> return None >> >> def allow_relation(self, obj1, obj2, **hints): >> return None >> >> def allow_migrate(self, db, app_label, model_name=None, **hints): >> is_legacy_db = db == self.legacy_database >> is_legacy_app = app_label in self.route_app_labels >> if is_legacy_db: >> return is_legacy_app >> else: >> return not is_legacy_app >> >> De esta forma, si ejecuto las migraciones con >> >> python manage.py migrate >> >> se migran las tablas que no son de la BD legacy y no son de la aplicación >> legacy. Pero además se incluyen migraciones (con SQL vacío) de los modelos >> de legacy. >> >> De la misma forma, si migro los modelos de legacy con >> >> python manage.py migrate --database=legacy >> >> se migran los modelos de legacy, pero además, se añaden entradas para >> todas las migraciones de las otras aplicaciones instaladas (sin SQL, con lo >> que no se crean/modifican tablas que no tocan). >> >> En ambos casos, python manage.py showmigrations y python manage.py >> showmigrations --database=legacy muestran todas las aplicaciones. >> >> Creo que esto es comportamiento esperado, pero ¿hay forma de que no >> salgan los modelos en las bases de datos que no los necesitan? ¿Estoy >> haciendo algo mal? >> >> ¡Muchas gracias! >> >> ----- >> Pau >> >> Python..., what else? >> _______________________________________________ >> Python-es mailing list >> Python-es@python.org >> https://mail.python.org/mailman/listinfo/python-es >> > > > -- > Juan Ignacio Rodríguez de León > Móvil (Spain): 605 890514 (Add +34 for International calls) > Mobile (UK): 07898648972 (Replace first 0 with +44 for International > calls) > E-Mail: euriba...@gmail.com > http://www.pythoncanarias.es/ > _______________________________________________ > Python-es mailing list > Python-es@python.org > https://mail.python.org/mailman/listinfo/python-es >
_______________________________________________ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es