Hey Russ,
On Jul 10, 4:21 am, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Thu, Jul 8, 2010 at 10:45 PM, Nowell Strite <now...@strite.org> wrote: > > Recently I started working on a project (django-versions) to enable > > versioning of model data with Mercurial. In doing so, I came across > > the need to have access to more data about the relationships that > > Django Related Manager's create. For example, I wanted to be able to > > access the instance of the model that a related manager was called > > from, as well as the field names for the forward and reverse > > relationship. > > You won't get any argument from me that this sort of metadata should > be available; however, I'm fairly certain it already is: > > artist1.songs.model_attname > ==> Artist.songs.field.rel.related_name The problem here is that as a reusable manager, I don't know that the "songs" descriptor object was used to call me, or that I was called from the artist1 instance, or even the Artist model for that matter. You were able to create this connection by knowing (outside of the Manager's self.XXXX scope) the relationship and as a result knowing to query the Artist model, or the "songs" Related Manager descriptor, etc. > > artist1.songs.related_model_instance > ===> artist1 (not sure why this one is required) The same is true, here. From an observation point of view, I could create this connection, however, programatically from within a re- usable manager I know nothing of the calling object. > > artist1.songs.related_model_attname > ==> Artist.songs.field.name > > Have I missed something? > > Yours, > Russ Magee %-) 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. 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? Thanks! Nowell Strite -- 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.
