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
