Thanks for the discussion - we considered the comments and suggestions and
came up with the following:
1) Create, in the case of a self-referring foreign key only, convenience methods
that are named less ambiguously - we suggest getParent and
getChildren. We are working on the necessary template modification.
2) The naming convention "RelatedBy" is used for clarity and to avoid method
name-collision when a particular column participates in more than one
foreign key. Its use on self-referring foreign keys is not technically
necessary or consistent. We perpetuated the use of RelatedBy because it was
already used in the template when generating the additional accessors for
an attribute that is also a foreign key in other tables. (The patch we
submitted originally added the accessor for the foreign key when it was
self-referring - i.e., the get children method.)
So it seems there is a choice:
a) Remove the use of "RelatedBy" for self-referring foreign keys - this would
change method names as they have previously existed. We will mitigate the
impact by continuing to generate the "RelatedBy" form of the methods and
deprecate them.
- or -
b) Continue the use of RelatedBy for self-referring foreign keys.
If everyone/anyone will indicate their preference, we'll submit an appropriate
patch.
Thanks
Scott Finnerty
-----Original Message-----
From: John McNally [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 13, 2002 3:36 PM
To: Turbine Torque Developers List
Subject: RE: [PATCH] Support recursive foreign key relationships
On Thu, 2002-06-13 at 13:14, Stephen Haberman wrote:
> > The table has a self-referential key to set up parent/child
> > relationships. The method getScarabModulesRelatedByParentId is a bit
> > ambiguous. When writing the template I was thinking a method named
> like
> > this should return results similar to a method named getParentModules.
> > What it will return is ChildrenModules. This is the reason for not
> > generating these methods. If others do not find this confusing, I am
> ok
> > with the patch.
>
> I agree that it's not the clearest thing in the world, but I would hope
> users would get it after a few tests, even if they don't at first.
>
> Given that you already trap for this parent/child foreign key reference
> situation, could you implement getParentModules/getChildModules instead
> of the ambiguous getModulesRelatedByParentId? I'm not familiar enough
> with the template to know whether it's possible or not and could be done
> generally for all (most) situations.
>
I think the method internals could be done generally. I'm not sure how
easy it is to generate a suitable method name generally. The other
method (getParentModules) will require using aliases which had not been
added to criteria when i first coded the templates, but it has since
been added.
john
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
