On 1/25/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/25/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> > Also, it would be cool if the _set stuff wasn't forced on us, there's
> > a disconnect between creating an attribute called 'sites' in your
> > model, and accessing that attribute via 'site_set'. Allowing users to
> > set the attribute name on both sides would require some trickery, but
> > it could be done. (I can think of a couple of ways.) That said, I can
> > live with the '_set' names.
>
> Good call about the "sites" thing. Really, that attribute name isn't
> used at all (from what I can tell)...hmmm. What are your ideas?
Either pass in the attribute name of the related object (or as I'd
like to call it, "the ugly way"):
class Article(models.Model):
sites = models.ManyToManyField(Site, related_attr='articles')
Or, steal an idea from SQLObject and allow strings rather class names
for OneToOne, ManyToMany, and ForeignKey (I think internally,
SQLObject uses the string to lookup the object from inside the current
module, but it's been awhile since I looked at it):
class Article(models.Model):
sites = models.ManyToManyField('Site')
That way people *can* define both sides with plain old attribute
assignment, but they don't *have* to. If someone *didn't* specify one
of the attributes, it should get created anyhow using the '_set' name.
This option would make the most sense if there was one more field type
that could define the 'other' side of a ForeignKey. Finding a decent
name for that field type might be challenging though ;)
Joseph
