Hey Federico, I just had a brief look at the code. If I understand the HStoreVirtualMixin.contribute_to_class() correctly and its implications regarding add_field(), I'd try to use cls._meta.add_field(self, virtual=True) instead of a simple cls._meta.add_field(self). That way the virtual fields shouldn't show up in migrations at all: https://github.com/django/django/blob/master/django/db/migrations/state.py#L357 -- The way the e.g. DictionaryField is implemented, when you put the schema into the deconstruct() output, contribute_to_class() should still be called generating the additional fields on its own.
Note that this is just a shot in the dark. I didn't try it out myself. /Markus On Tuesday, April 21, 2015 at 7:53:04 PM UTC+2, Federico Capoano wrote: > > 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/ef6c0525-ffb2-4bc6-8d14-706edd65a142%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
