convore.json/groups/django-community/query-composability/messages.json

[{"user_id": 214, "stars": [], "topic_id": 11381, "date_created": 1299535629.0761399, "message": "Not sure how much work that'd be without trying it.", "group_id": 81, "id": 291956}, {"user_id": 225, "stars": [], "topic_id": 11381, "date_created": 1299535335.54247, "message": "Like if I wanted to find all stickers applied to public content, I would want to do Stickers.objects.filter(content__visibility__in=[public, whitelisted]), which the visibility_public Q object wouldn't do (it would fail looking for a visibility field on the Stickers object)", "group_id": 81, "id": 291910}, {"user_id": 214, "stars": [], "topic_id": 11381, "date_created": 1299535621.756083, "message": "The idea would be that it would only generate the actual Q object when called, until then it would just collect filters and be combinable with boolean operators like Q objects are.", "group_id": 81, "id": 291954}, {"user_id": 214, "stars": [], "topic_id": 11381, "date_created": 1299535580.5810239, "message": "Hmm. First thing that comes to mind is your own wrapper around Q objects that parameterizes the \"join prefix\", so in the end you'd do Stickers.objects.filter(visibility_public(\"content\")).", "group_id": 81, "id": 291948}, {"user_id": 225, "stars": [], "topic_id": 11381, "date_created": 1299535206.8895221, "message": "On Canvas we have a visibility field, with a dozen or so options. (Hidden, Public, Moderated, Unpublished, etc)", "group_id": 81, "id": 291884}, {"user_id": 225, "stars": [], "topic_id": 11381, "date_created": 1299535255.299304, "message": "We're trying to use Q objects for composability, so I could do Comment.objects.filter(visibility_public) where visibility_public = Q(visibility__in=[public, whitelisted])", "group_id": 81, "id": 291899}, {"user_id": 225, "stars": [], "topic_id": 11381, "date_created": 1299535341.3168011, "message": "Any suggestions, convore?", "group_id": 81, "id": 291911}, {"user_id": 3580, "stars": [], "topic_id": 11381, "date_created": 1299536696.237762, "message": "Is there a reason you're using Q objects for reusability instead of chained filter calls? Comments.visibility_public.filter(other custom stuff).. where def visibility_public: return cls.objects.filter(visibility_in=[public, whitelisted])", "group_id": 81, "id": 292080}, {"user_id": 3580, "stars": [], "topic_id": 11381, "date_created": 1299536728.508363, "message": "curious if that's a bad way to get re-use since I've been doing it a fair bit :|", "group_id": 81, "id": 292083}, {"user_id": 225, "stars": [], "topic_id": 11381, "date_created": 1299535282.247061, "message": "AFAICT there's no way to reuse Q objects, or any other form of query reuse, when you're using them as filters on joins", "group_id": 81, "id": 291903}, {"user_id": 3580, "stars": [], "topic_id": 11381, "date_created": 1299537812.992614, "message": "oh, right.. mostly when these get reused I put them in mixins.", "group_id": 81, "id": 292191}, {"user_id": 3580, "stars": [], "topic_id": 11381, "date_created": 1299537967.548949, "message": "gotcha.. I guess I can see value in that they're easily re-used across managers that way.. course so are classmethods on the model.", "group_id": 81, "id": 292202}, {"user_id": 1736, "stars": [], "topic_id": 11381, "date_created": 1299537800.0581429, "message": "@carljm Common manager base class would get you pretty far though (though there is still the manager/queryset method annoyance)", "group_id": 81, "id": 292190}, {"user_id": 214, "stars": [], "topic_id": 11381, "date_created": 1299537679.513576, "message": "@phill That's not bad (though I'd generally put the method on a Manager, not a model classmethod). It doesn't achieve quite the same level of reusability if you're actually reusing similar queries on tons of different models though, you have to stick that method separately onto each model (or use a mixin or something, in which case you're back to a very similar parameterization problem).", "group_id": 81, "id": 292186}, {"user_id": 3580, "stars": [], "topic_id": 11381, "date_created": 1299537849.1972771, "message": "out of curiosity.. what's the upside in putting them on a manager? I guess I suspected that was better practice, but I'm not sure why.. and at least half of my models don't have custom managers.", "group_id": 81, "id": 292198}, {"user_id": 1736, "stars": [], "topic_id": 11381, "date_created": 1299537888.4501791, "message": "@phill General convention is that most query-related classmethods should instead be manager instance methods", "group_id": 81, "id": 292199}, {"user_id": 1736, "stars": [], "topic_id": 11381, "date_created": 1299538014.3168199, "message": "@phillThe main difference is you can have multiple manager instances on a model, though I will admit thats very rare :-)", "group_id": 81, "id": 292207}, {"user_id": 225, "stars": [], "topic_id": 11381, "date_created": 1299609496.6414371, "message": "@carljm That solution's the best thing I've heard so far.", "group_id": 81, "id": 298304}, {"user_id": 225, "stars": [], "topic_id": 11381, "date_created": 1299609424.8100929, "message": "Right, I tried filter function and common manager base class and neither of them fix the specific redundancy I was mentioning, where you have to do the same type of filter but across different joins", "group_id": 81, "id": 298290}]