Thomas Güttler

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...

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....

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...

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...

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...

Yes, the problem here is **not** technology. It is human fear. You don't need to care about 1M NULL values in columns. Modern databases handle this very well. Related: Jacob...

Thank for the feedback. Please ping me, if there is something missing in the list.

@procedural could you please elaborate? What should I learn?

Are there any docs for ThreadedTestFTPd? If I had known this in advanced, then I would used your solution :-) (and saved some time)

I like this API. ``` temp_dir = tempfile.mkdtemp() with testutils.FTPServerContext(temp_dir) as ftp_context: connection = your_ftp_lib.connect('127.0.0.1', ftp_context.port) ... ``` But this starts the server for every test. In my case this...