views:

225

answers:

1

I have a project with an FAQ app. The app has models for FAQ (written by the site authors) and UserFAQ (written by users-- not just a clever name). I want to return all entries, FAQ or UserFAQ that match certain conditions, but I also want to exclude any UserFAQs that don't match a certain criteria. Ideally, it would looks something like:

faqs = FAQ.objects.filter(question__icontains=search).exclude(show_on_site=False)

Where "show_on_site" is a property that only UserFAQ objects have. That doesn't work because the filter craps out on the parent class as it doesn't posses the property. What's the best way of doing this? I came across this snippet, but it seems like overkill for what I want to do.

+1  A: 

In your position, absent a need to have two tables, I'd be tempted to have one FAQ model/table with is_user_faq and show_on_site fields.

Sometimes it helps when modeling data to organize it for simple and fast access. While model inheritance has some appeal, I've found it it's often easier to avoid using it.

Dave W. Smith
I really don't care for that answer. If the best solution in a framework is to break OOP principles, it'd be a bad framework. It looks like there's a solution to this coming in Django 1.1. I'm just looking for a way to filter some items out of a queryset; breaking the design of the objects can't be the best solution.
Tom
@Tom Careful with words like "break". You're trying to map an OO design to a relational data store (which is not OO). That's fundamentally a hard thing to do, and the abstraction leaks. You may prefer the inheritance-based design for your business objects, but redesigning them in a way that maps more closely to the data store is not "breaking the design," it's using a different design that has different advantages (for instance, it means you bang your head against ORM limitations a lot less). Not saying there isn't a way to do it your way, but this is a quite reasonable answer.
Carl Meyer