I have tried this patch and it does compile cleanly but I don't think
the methods work the way that is expected. For example:
+ public List getScarabModulesRelatedByParentId(Criteria criteria)
throws TorqueException
+ {
...
+ criteria.add(ScarabModulePeer.PARENT_ID, getModuleId() );
+ collScarabModulesRelatedByParentId = ScarabModulePeer.doSelect(criteria);
+ }
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.
john mcnally
On Thu, 2002-06-13 at 11:43, Martin Poeschl wrote:
> Scott Finnerty wrote:
> > Could someone apply this patch and commit the changes or explain why this change
>is incorrect or inappropriate? I'd be happy to consider alternatives.
> >
> > Thanks.
>
> is anyone expecting any problems with this patch??
>
> i don't know why the check exists ...
>
> martin
>
> >
> > -----Original Message-----
> > From: Scott Finnerty
> > Sent: Tue 6/4/2002 5:25 PM
> > To: [EMAIL PROTECTED]
> > Cc:
> > Subject: [PATCH] Support recursive foreign key relationships
> >
> >
> >
> > (I submitted this before but realized that I may not have explained it
> > simply enough and I didn't word wrap for text email readers... my bad.)
> >
> > Attached is a patch that allows for a table to have a foreign key to
> > itself. An example of such a relationship would be a folder table where
> > each record could have a reference to a parent folder.
> >
> > Currently there is a check in the Object.vm template that short circuits
> > the generation of the accessors to objects related by foreign key if the
> > name of the local table is the same as the foreign table. Does anyone
> > have any background on why this short circuit was put in place? We're
> > hoping it was just because the issue of handling recursive foreign key
> > relationships was deferred.
> >
> > Scott Finnerty
> >
> > Index: jakarta-turbine-torque/src/templates/om/Object.vm
> > ===================================================================
> > RCS file: /home/cvspublic/jakarta-turbine-torque/src/templates/om/Object.vm,v
> > retrieving revision 1.31
> > diff -u -r1.31 Object.vm
> > --- jakarta-turbine-torque/src/templates/om/Object.vm 28 May 2002 01:00:16
>-0000 1.31
> > +++ jakarta-turbine-torque/src/templates/om/Object.vm 30 May 2002 21:39:23
>-0000
> > @@ -331,12 +331,11 @@
> > ##
> > #foreach ($fk in $table.Referrers)
> > #set ( $tblFK = $fk.Table )
> > - #if ( !($tblFK.Name.equals($table.Name)) )
> > #set ( $className = $tblFK.JavaName )
> > #set ( $relatedByCol = "" )
> > #foreach ($columnName in $fk.LocalColumns)
> > #set ( $column = $tblFK.getColumn($columnName) )
> > - #if ($column.isMultipleFK())
> > + #if ($column.isMultipleFK() || $tblFK.Name.equals($table.Name) )
> > #set ($relatedByCol= "$relatedByCol$column.JavaName")
> > #end
> > #end
> > @@ -563,7 +562,7 @@
> >
> > return $collName;
> > }
> > - #end #end #end #end
> > + #end #end #end
> >
> > ## ===========================================================
> > #*
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > --
> > 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]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
