Isn't this one of the main reasons why the hasMany and hasOne tags (and the object tag for that matter) support aliases? In other words, I'm not sure what else could be done?
I'm not sure either... Maybe force aliases (throw an error where they are missing) in situations where you have related objects with duplicate relationship names? Maybe it just needs to be documented? On 9/8/06, Brian Kotek <[EMAIL PROTECTED]> wrote:
Isn't this one of the main reasons why the hasMany and hasOne tags (and the object tag for that matter) support aliases? In other words, I'm not sure what else could be done? On 9/6/06, Mark Stanton <[EMAIL PROTECTED]> wrote: > Hi All > > I don't know if this is a bug or expected behaviour, but regardless I > think it should be handled a little better as it is a nightmare to > debug... > > I have a situation where I have two tables as follows: > > <object name="Agency"> > > <hasMany name="Agency"> > <relate from="AgencyUUID" to="ParentAgencyUUID"/> > </hasMany> > > <hasMany name="SON"> > <link name="SON_Agency"/> > </hasMany> > > </object> > > <object name="Contract"> > <hasMany name="Contract"> > <relate from="ContractUUID" to="parentContractUUID"/> > </hasMany> > <hasMany name="Agency"> > <link name="Contract_Agency"/> > </hasMany> > </object> > > <object name="Contract_Agency"> > <hasOne name="Contract"> > <relate from="ContractUUID" to="ContractUUID"/> > </haContracte> > <hasOne name="Agency"> > <relate from="AgencyUUID" to="AgencyUUID"/> > </hasOne> > </object> > > In plain english, I've got a recursive heirarchy of agencies, each > agency can have many contracts and contracts can be amended repeatedly > by posting a new contract with a parentContractUUID pointing back at > the original contract. > > The problem is that in some conditions the iterator tries to create > the join from Agency to Contract using the Contract_Agency table, but > it gets mixed up between the <hasOne name="Contract"> on the > Contract_Agency table and the <hasMany name="Contract"> on the > Contract table. > > The end result is an "Field Does Not Exist: The field > 'parentContractUUID' does not exist for the 'Contract_Agency' object." > error in the abstractMetadata.cfc. > > I can work around this easily by aliasing the contract amendment > relationship (<hasMany name="Contract" alias="ContractAmendment">). > > As far as I can tell the code that makes the leap from one > relationship to the other is: > > <!--- find the relationship to/from this object ---> > <cfif getObjectMetadata().hasRelationship(arguments.relationshipAlias)> > <cfset relationship = > getObjectMetadata().getRelationship(arguments.relationshipAlias) /> > > <cfelseif ToObjectMetadata.hasRelationship(arguments.relationshipAlias)> > <cfset relationship = > ToObjectMetadata.getRelationship(arguments.relationshipAlias) /> > > ...in object.cfc (around line 177). > > My main concern is that it has take us a long time to work it all out > - others could easily fall into the same trap and when they do its a > long road to working out what went wrong. > > What do you guys think? Should this be improved? If so how? > > -- > Mark Stanton > Gruden Pty Ltd > http://www.gruden.com > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > Reactor for ColdFusion Mailing List > [email protected] > Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- Mark Stanton Gruden Pty Ltd http://www.gruden.com -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
