On 8 kesä, 13:43, Russell Keith-Magee <[email protected]> wrote: > That's certainly an interesting use case. However, I can think of at > least 2 ways it could be mitigated. > > One way would be to treat this as part of the contract of a pluggble > app. We've always said that an app should do one thing, and one thing > only; providing a *single* swappable model candidate, and any > associated support (e.g., forms, admin declarations) would seem to fit > that definition fairly well. In this context, a "library" of reusable > User models is really just a collection of apps, one of which will be > installed in your project. The CMS with a range of User model options > would provide them as a series of apps, one (and only one) of which > needs to be installed.
We might want to have two user models already in the auth.models. The current User, and then an "ImprovedUser", which is like the default user, but has the worst limitations lifted (email field can be 255 chars long, username restrictions lifted, ...). It seems the current implementation would not allow for this, because only one model could define itself as swappable, and the other would get installed even if it wasn't needed. For our use case this would work as we control global_settings.py, and we can use the hidden swappable attribute for both models, but I guess the ImprovedModel/BackwardsCompatibilityModel pattern isn't such a rare case. To make the swappable option nicer to use for 3rd party apps a better solution than different app for each swappable model would be welcome. > > The model_label_for_default_model can't be defined anywhere in the > > current implementation. The Model._meta.swapped uses: > > return self.swappable and getattr(settings, self.swappable, None) > > not in (None, model_label) > > Sure - but model_label_of_default_model doesn't *need* to be defined > anywhere - it's the model that has swappable=XXX defined on it. I was driving for the use case where you define multiple different models for the same "slot" using the swappable option. If there can be only one model with swappable set for each slot, then there is no problem here. > Again - for me this is one of those things where it's all about the interface. > > In this example, your end problem isn't "I need to issue a query with > Q(creator__last_name__ilike=q)|Q(creator__first_name__ilike=q)" -- > it's "I need to search for document creator by name", and *that* is > what your interface should be defining. If your interface spec said > you had to provide a "find_document_by_author()" method, and one > particular implementation happens to use that query, then you've just > solved the problem. The specific document attributes *should* be > irrelevant -- and if they aren't, you haven't defined your document > interface well enough. > > It's impossible to claim that every model will be usable in every > circumstance. At some point, you have to lock down an interface > specification, which will define what it is possible to do in a > 'generic' sense with your swappable model. This isn't some new concept > we're inventing here - interfaces have been a major part of more than > one language for decades. Luckily, with Python, we get the benefits of > interfaces without needing to be strict about it -- we can rely on > duck typing, rather than rigorous and inflexible compile-time checks. The problem is that we have no ability to define ORM interface for the model. The ORM doesn't allow for this. It would be nice, but you can't have everything. I am not claiming this is a blocker issue at all, I was just wondering if there were any plans to define an ORM interface for the model. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
