#25068: Metaclass conflict when doing createmigrations in ModelState.render
-------------------------------------+-------------------------------------
Reporter: kosz85 | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.8
Severity: Normal | Resolution:
Keywords: metaclass conflict | Triage Stage: Accepted
createmigrations |
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by kosz85):
Yeah, It's quite hard topic, but your current solution just doesn't work
with code that work on South, and you have to take into account, that
there may be more then 1 metaclass. Let's discuss and think on some
solution but first one thing:
'''All your points are occurring also in current version. My fix is only
dealing with multiple inheritance of metaclasses.''' Currently you also
can have custom metaclass and you can change it without any note at
migrations, the only thing is that current migrations support only 1 such
metaclass now, and break on multiple inheritance.
1. I don't understand your question :) It would be changed, and derived
class would be changed. It's rather unlikely that you will be changing
`ModelBase` itself, as it's more like you want to just add some metaclass
functionality. The new metaclass will have both functionalities from
`ModelBase` and your custom metaclass. If I understand correctly what you
would like to do, so to change the custom `MyModelBase` with `ModelBase`
it probably would work in most case, but you will need to modify base
classes to be able to create class object. In my opinion this solution
would be even scarier.
2. No I didn't do anything like that. But do we really need it? Currently
`BaseModel` is also not listed, and if I will add normal metaclass with
single not multiple inheritance it will work the same way as it's now
without any notes that there is different metaclass. But of course it's
probably possible to list metaclasses, but I don't really think it's
needed. The change in fileds will be noticed, options are still part of
`BaseModel`, custom metacalss doesn't change it. In most cases custom
metaclasses are for some tricks, like global registry, singletons, class
definitions validators, and they are not used for dealing with models
itself. That in my case, maybe I'm wrong, but I don't see much more danger
here comparing to current solution.
3. It's possible to list metaclasses, the code that is constructing
metaclass is doing it in fact it's just `map(type, bases)` and you can go
with it like you will do with normal bases, as metaclass is also a class,
but with base of `type`. So it's possible to reuse same code for
construction bases list. Thought managers are quite different being.
4. Yes, and I don't see any problem with it. Thought as I said before, I
don't think it's this kind of metaclass :) Normally I would use 2
different mixins for custom metaclass and abstract Model with fields, as
it would be cleaner and easier to maintain. Also that way I can reuse
metaclass in many models. But of course you can also try to inherit your
metaclass from ModelBase and made it custom, but you can do it even now
and you have to deal with same problems you listed, but without error I
reported. My fix solves only multiple inheritance problem, with witch
`ModelState` couldn't deal with.
--
Ticket URL: <https://code.djangoproject.com/ticket/25068#comment:14>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.6938350cdb5d3a4c11a025a05e00a156%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
