Hi everyone, some time ago I submitted this ticket: https://code.djangoproject.com/ticket/23159 - because we had problems with the migration framework.
To sum up, the django-hstore <https://github.com/djangonauts/django-hstore> library has a VirtualField implementation which maps hstore keys (by supplying a schema parameter) to virtual fields so that they can be used on models, the admin, and even in django-rest-framework APIs. After some interactions with Andrew Godwin, I implemented his suggestion, that was to let db_type() return None, which worked well, until this other issue came up: https://github.com/djangonauts/django-hstore/issues/103 In that case the migration framework would throw an error even if db_type returned None. Luckily, Tim Graham suggested me how to reach the no-op branch of the migration framework: https://github.com/django/django/blob/190afb86187e42c449afe626cff31f65b4781aa2/django/db/backends/base/schema.py#L470-L475 I met Florian Apolloner at Pycon Italy, so I took advantage of his presence to ask some questions and hear some feedback, which I really appreciated and which really helped me. I have been able to replicate the bug in a test case and implement the workaround, now comes the interesting part: here's the workaround code: https://github.com/djangonauts/django-hstore/commit/47f5aa05834365e2d6c41234e03b028a827ee91c As you can see, I had to add quite some ugly code just to enter that no-op branch.... there must be a better way! :-D I talked with Florian about the possibility to have some way to flag virtual fields in order to enter that no-op branch more easily and he was not very sure about it but nonetheless he encouraged me to bring up this issue here. One of the reasons he was not sure is "what happens if a field has the skip flag and then it doesn't or viceversa?" So I thought about proposing a definition of virtual field: "A virtual field is a model field which it correlates to one or multiple concrete fields, but doesn't add or alter columns in the database." By following this definition I suppose we can: - allow the migration framework to enter the no-op branch if analyzing a virtual field - if a concrete field becomes virtual (i can't immagine the use case but i'm reasoning just in case), the migration framework will drop the column, and the developer will have to adjust the migration in order to avoid losing data - if a virtual field becomes concrete, the migration framework will add the right column and the developer will have to adjust the migration in order to correctly fill the concrete field with the data that is probably stored in another concrete field Thank you for your attention. Best regards Federico Capoano -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1fa02745-5c39-4b18-871e-c89db9c87966%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
