convore.json/groups/django-community/multiple-managers-or-multiple-methods-on-a-single-manager/messages.json

[{"user_id": 281, "stars": [{"date_created": 1307636231.331789, "user_id": 32942}], "topic_id": 38496, "date_created": 1307462272.5196791, "message": "I generally prefer the later, https://bitbucket.org/carljm/django-model-utils/src has some nice helpers to make implementing that super easy", "group_id": 81, "id": 1322835}, {"user_id": 5980, "stars": [], "topic_id": 38496, "date_created": 1307462206.2596779, "message": "I'm about to start a big project with lots of business logic that will be expressed in the model layer. I have a fairly fundamental question, and I'm not sure what the best practice is. In short, should my API look like this:", "group_id": 81, "id": 1322818}, {"user_id": 5980, "stars": [], "topic_id": 38496, "date_created": 1307462224.4039919, "message": "Post.objects.published()\nPost.objects.unpublished()\n", "group_id": 81, "id": 1322824}, {"user_id": 5980, "stars": [], "topic_id": 38496, "date_created": 1307462326.461139, "message": "@SeanOC but django-model-utils PassThroughManager makes the former super easy too..", "group_id": 81, "id": 1322844}, {"user_id": 5980, "stars": [], "topic_id": 38496, "date_created": 1307462225.002157, "message": "or this:", "group_id": 81, "id": 1322825}, {"user_id": 5980, "stars": [], "topic_id": 38496, "date_created": 1307462225.621655, "message": "Post.published.all()\nPost.unpublished.all()", "group_id": 81, "id": 1322827}, {"user_id": 281, "stars": [], "topic_id": 38496, "date_created": 1307462393.0890701, "message": "sure, I suppose the preference has little to do with the implementation difficulty :)", "group_id": 81, "id": 1322859}, {"user_id": 281, "stars": [], "topic_id": 38496, "date_created": 1307462440.6091349, "message": "I like the multiple manager setup because it's less verbose while still being very clear", "group_id": 81, "id": 1322878}, {"user_id": 35590, "stars": [], "topic_id": 38496, "date_created": 1307521409.0502911, "message": "I'm all for the latter, multiple manager approach. Though, if you have lots of managers per model, the model might start to feel cluttered, which would take me back to the multiple methods version.", "group_id": 81, "id": 1334879}, {"user_id": 5980, "stars": [], "topic_id": 38496, "date_created": 1307523376.7692831, "message": "Hmm.. if you decide the model starts to \u201cfeel cluttered\u201d half way through the project and change its API, you'd have to touch all the code that calls it.", "group_id": 81, "id": 1335045}, {"user_id": 5980, "stars": [], "topic_id": 38496, "date_created": 1307523485.326889, "message": "It feels like there should be a standard way to do it from the start. Instinctively, it feels like namespacing everything under objects makes more sense than cluttering the model with managers, but the fact that both options exist suggests that there might be some sort of fundamental conceptual difference between the two.", "group_id": 81, "id": 1335058}, {"user_id": 17897, "stars": [], "topic_id": 38496, "date_created": 1307526556.6476679, "message": "if always thought that instance specific or static stuff for exactly 1 Post stuff goes on the model and the other on the manager. That's the way I'd do it.", "group_id": 81, "id": 1335255}, {"user_id": 17897, "stars": [], "topic_id": 38496, "date_created": 1307527603.6227319, "message": "I wouldn't create more than 2-3 managers and then have methods on the managers.", "group_id": 81, "id": 1335329}, {"user_id": 5980, "stars": [], "topic_id": 38496, "date_created": 1307527258.294534, "message": "Yes, that's not the issue. The question is whether to have a single custom manager (probably called \"objects\") with multiple methods to encapsulate your table-level stuff, or whether to add multiple separate managers.", "group_id": 81, "id": 1335292}, {"user_id": 17897, "stars": [], "topic_id": 38496, "date_created": 1307527656.7807741, "message": "I guess the problem is if you can map distinct functionality to the managers before hand.", "group_id": 81, "id": 1335336}, {"user_id": 17897, "stars": [], "topic_id": 38496, "date_created": 1307527567.3034191, "message": "duh, yes of course. I read your examples wrong. :)", "group_id": 81, "id": 1335323}, {"user_id": 5980, "stars": [], "topic_id": 38496, "date_created": 1307527583.0429831, "message": "Thinking about it, I suppose an obvious argument for the former is chainability. I could write Post.objects.published().written_by(my_user_object).older_than(my_date_object).. can't really do that if those methods are on different managers. Thoughts?", "group_id": 81, "id": 1335325}, {"user_id": 24931, "stars": [], "topic_id": 38496, "date_created": 1307569761.191927, "message": "@j4mie why couldn't one do Post.published.all().written_by(my_user_object).older_than(my_date_object) ? It seems that would also work as both styles just return queries with filters applied to them.", "group_id": 81, "id": 1343094}, {"user_id": 11646, "stars": [], "topic_id": 38496, "date_created": 1307582717.198302, "message": "@streeter With model-utils you can do just that. You extend the queryset instead of extending the manager.", "group_id": 81, "id": 1344736}, {"user_id": 24931, "stars": [], "topic_id": 38496, "date_created": 1307583013.8466749, "message": "@ricobl thats what I thought.", "group_id": 81, "id": 1344770}, {"user_id": 5980, "stars": [], "topic_id": 38496, "date_created": 1307788356.8995421, "message": "@streeter yes, you could do that, any extra managers would have to use the same QuerySet subclass to get the same filter methods. (so you could do Post.published.written_by(someone) or Post.unpublished.written_by(someone)).", "group_id": 81, "id": 1369396}, {"user_id": 5980, "stars": [], "topic_id": 38496, "date_created": 1307788399.9456611, "message": "But then why (to continue the above example) should published/unpublished be separate managers, but written_by be a QuerySet method?", "group_id": 81, "id": 1369397}, {"user_id": 4383, "stars": [], "topic_id": 38496, "date_created": 1308107127.3773341, "message": "but with multiple managers you cannot", "group_id": 81, "id": 1397187}, {"user_id": 4383, "stars": [], "topic_id": 38496, "date_created": 1308107084.12537, "message": "I generally don't like to use multiple managers since there are lots of parts that use the default manager and don't provide a way to use other managers.", "group_id": 81, "id": 1397165}, {"user_id": 4383, "stars": [], "topic_id": 38496, "date_created": 1308107177.6326561, "message": "The admin is another place where the default manager is used without any real way of using another manager.", "group_id": 81, "id": 1397196}, {"user_id": 4383, "stars": [], "topic_id": 38496, "date_created": 1308107120.603308, "message": "If you use the first approach you can do obj.rel_object_set.unpublished()", "group_id": 81, "id": 1397185}, {"user_id": 4383, "stars": [], "topic_id": 38496, "date_created": 1308107096.2003031, "message": "obj.rel_object_set.all() being one.", "group_id": 81, "id": 1397174}, {"user_id": 34431, "stars": [], "topic_id": 38496, "date_created": 1308135724.4303541, "message": "I am only coming to grips with all this, but I think multiple managers are useful when you want each manager to represent a different base queryset and any further methods specific to that base queryset should be included in that manager. General logic across all querysets for that model should be implemented as methods on the default manager.", "group_id": 81, "id": 1399639}, {"user_id": 34431, "stars": [], "topic_id": 38496, "date_created": 1308135924.458288, "message": "To that extent you could have a hierarchy where you define general methods and logic on your model in the default manager, and when it makes sense to create a new manager to represent a specific queryset (like all the posts that are published) you can subclass the default manager, retain all the functionality that the default manager provides and overwrite the get_query_set() method", "group_id": 81, "id": 1399654}, {"user_id": 34431, "stars": [], "topic_id": 38496, "date_created": 1308135941.66589, "message": "I'm thinking out loud so this could not make any sense at all", "group_id": 81, "id": 1399655}]