Child class in different app

[guettli]

trafficstars

There is a central app core which defines a class Plugin and there is an optional app my_plugin which subclasses from Plugin.

I run manage.py schemamigration my_plugin --auto, but Nothing seems to have changed..

I need to run manage.py schemamigration core --auto to get the changes dumped to a migration file.

This does not work, since core does not depend on my_plugin. The plugin should be optional. The relevant schema migrations need to be in the app of my_plugin.

Did you understand my problem?

What can I do?

[craigds]

I think I understand the problem.

You're altering a core table but you want it to be done as a my_plugin migration, so that users without my_plugin enabled can run the core migrations without adding the my_plugin fields.

1. Could you manage.py schemamigration core --auto but then move the generated migration into my_plugin/migrations/ ?
2. Consider not doing this? Users having different table structure based on your installed plugins could cause issues. For instance if someone removed my_plugin and didn't first reverse-migrate, they'll end up with the wrong table structure for their app. If it were my app I'd try hard to make the table structure the same regardless of what plugins are installed.

[guettli]

Thank you craigds for your answer.

Solution 1 (copy created migration file from core-app to plugin-app) is exactly what I did short after I created this issue. It worked.

Solution 2: Consider not doing this? .... I need plugins and the core does not now all plugins. The core knows some plugins, but I don't want to enforce this. If I would, I can't call it "plugin", since it is required.

Background: A plugin can be created by different people and different companies. There is no central version control for core and plugins.

Is it possible to alter typed models, so that south creates the migrations per plugin? Like the copy solution?

How could this be done?

[guettli]

I thought about this again:

In traditional DB design this pattern is wide spread and best practice:

There is a core application. It provides the database an some base tables. Optional third party plugin-apps are allowed to create tables in this database.

With Single-Table-Inheritance the design "a plugin-app is allowed to create new tables" changes to "a plugin-app is allowed to create new columns".

Like in traditional DB design the core app does not know all tables, since some are optional and provided by third party packages, with STI we have: The core app does not know all columns of its tables.

At first this makes FUD (Fear, Uncertainty and Doubt), but I personally like STI very much.

.... at the moment I only see this small problem, that south needs to create the migrations in the plugin app, not the core app.

[guettli]

Next (small) trouble ... I did some simple modification to my plugin (a simple model not inherited from core). Now --auto refuses to work:

modwork_eins_dtg@workdevel114:~$ manage.py schemamigration modwork_modarch --auto
You cannot use automatic detection, since the previous migration does not have this whole app frozen.
Either make migrations using '--freeze modwork_modarch' or set 'SOUTH_AUTO_FREEZE_APP = True' in your settings.py.

The solutions suggested by south did not help.

My solution:

Past: I copied the migration from core-app to plugin-app. Unfortunately now south does not want to guess he current DB schema.

Now I created an empty migration which freezes core-app and plugin-app. Copied the freezed models (code below forward()/backward() methods) to the copied migration. Deleted the empyte migration, and now the great --auto feature worked again.

[craigds]

Im not sure this core/plugin situation is well suited to STI, since STI necessarily tangles core and plugins together. You might be better off using multiple tables so you can keep core independent of plugins. On 11/07/2014 1:51 AM, "Thomas Güttler" [email protected] wrote:

Next (small) trouble ... I did some simple modification to my plugin (a simple model not inherited from core). Now --auto refuses to work:

modwork_eins_dtg@workdevel114:~$ manage.py schemamigration modwork_modarch --auto You cannot use automatic detection, since the previous migration does not have this whole app frozen. Either make migrations using '--freeze modwork_modarch' or set 'SOUTH_AUTO_FREEZE_APP = True' in your settings.py.

I copied the migration from core-app to plugin-app. Unfortunately now south does not want to guess he current DB schema.

My solution: create an empty migration which freezes core-app and plugin-app. Copied the freezed models (code below forward()/backward() methods) to the copied migration. Deleted the empyte migration, and now the great --auto feature worked again.

Reply to this email directly or view it on GitHub https://github.com/craigds/django-typed-models/issues/21#issuecomment-48606652 .

[guettli]

Hi, i moved the generated migration into my_plugin/migrations/ and everything works fine. Thank you for your support.

I don't want to close this issue, since I think it should be documented.

[guettli]

My solution which uses typedmodels is live since some days. All works well. The way descripted in this tickets works fine: The core-app defines a PluginBase and third party apps can implement this API by (single table) inheritance. The only thing which is not perfect at the moment: if you create a schemamigration with south, south does create the migration file always in the core-app. But a simple move (and renumber) helps.

Thank you very much for django-typed-models