Hi Nowell, First off -- apologies for taking so long to get back to you.
On Sun, Jul 11, 2010 at 10:54 PM, Nowell Strite <now...@strite.org> wrote: > Hey Russ, > > In the Artist example there are actually two many to many fields > pointing to songs (songs, and best_songs) so currently when you call > artist.songs or artist.best_songs, a new related manager for the Song > model is created, however, it does know know from where it was > created, only that self.core_filters = > 'some_filter_to_return_the_desired_results'. Ideally, programatically, > a manager that can be assigned to any model, should be able to upon > being accessed in a related fashion, know the details of the calling > model, which currently is not the case. I'm not sure I necessarily agree with this last point. For one thing, it wouldn't be consistent with the rest of Django; a Field instance doesn't know which model it belongs to, for example. The field contains everything it needs to know in order to format/handle data; it knows everything about itself; but it knows nothing about where it is being used. > For an example of the use case for why I want to access this type of > meta-data dynamically you could take a look at > http://github.com/nowells/django-versions/blob/master/versions/managers.py. > The basic case here is that I need to version the state of models and > their relationships. In order to be able to do that, I rely on when > you access a related manager (i.e. artist1.songs) that the resulting > manager, can then filter and alter the results to return the state of > the manytomany relationship based on what object is calling it (in > this case, at revision 1 of the artist object, it may only have had 5 > songs, and 1 best song, but at revision 10, it may have had 50 songs > and 5 best songs). So my desire would be that when I call > artist1.songs, the songs related manager knows from where it is being > called, and can interrogate arbitrary metadata about the calling > object, and alter it's behavior accordingly. > > I hope that I didn't dive too deep into my current use case, since > that use case if fairly complex. > > Does that make sense? I think I understand the use case, but I'm not sure I agree that the metadata you're expecting should be exposed in the way you describe. My take on your situation is that you're not really capturing the state of the manager, because the manager by itself doesn't have state. It's been constructed with the variables it needs to know about in order to execute the appropriate queries to add/remove objects from the relations that it represents. However, it's ultimately just a way to wrap functionality into an object that behaves a bit like an attribute. The object with state is the instance; that's the thing that should be versioned, and the metadata you need is already available there. The best analogy I can think of is the following: class MyObject(object): @property def foo(self): return 'bar' foo is a property of MyObject instances; it exists, but it doesn't really have state outside the context of a specific object instance. It doesn't embody anything about MyObject by itself. If you were going to record the state of MyObject, you might use foo to determine that state, but you wouldn't really be recording the state of an instance of foo. Does that make any sense? Or have I missed the point again? Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
