So it seems that you have a double up for d_uid in your configuration. Why not use a <manytoone> in your <compositeid> http://docs.transfer-orm.com/wiki/Transfer_Configuration_File.cfm#compositeid
And then do away with the <property> definition ? Mark On Thu, May 28, 2009 at 3:14 AM, Kerr <[email protected]> wrote: > > Hi all, I've been playing around with Transfer ORM off and on for some > time, and have recently been getting into how Transfer handles > manytoone / onetomany relationships and composite keys. At the > database level, I'm a big believer in composite keys where they make > sense. I have a large number of tables in various apps with two > column composite keys in lieu of an arbitrary ID column. It seems, > however, that the way I'd like to model my objects, is not working > well with Transfer when saving objects... or maybe I'm just not seeing > the Transfer way of doing things. Here is an example of what I'd like > to do. > > A simplified sample Transfer config: > > <object name="developer" table="developers"> > <compositeid> > <property name="d_request_id" /> > <property name="d_uid" /> > </compositeid> > > <property name="d_request_id" type="numeric" /> > <property name="d_uid" type="string" /> > <property name="d_date_insert" type="date" /> > <property name="d_uid_insert" type="string" /> > > <manytoone name="emp"> > <link column="d_uid" to="employee"/> > </manytoone> > </object> > > <object name="employee" table="employees"> > <id name="uid" type="string" /> > <property name="first_name" type="string" /> > <property name="last_name" type="string" /> > <property name="title" type="string" /> > <property name="work_phone" type="string" /> > </object> > > The developer object is an object that contains a composite key of a > work request ID (not modeled here for simplicity) and an employee ID. > The employee object is simply a lookup table that contains metadata on > company employees. In my trials, I have realized that when using the > property attribute of a composite key, that property cannot be > declared in the same object as the database will throw a "column > appears more than once" error. I have gotten around this issue a > couple ways: > > A) Using an arbitrary ID column in lieu of the composite key. > B) Changing the manytoone relationship to a onetomany on the employee > object, then changing the property attribute of the composite ID to a > parentonetomany. > > I don't relish either of these scenarios. I would not like to add > arbitrary columns to my schema, and I believe most would agree. So, > that leads me down the path of onetomany, which I don't see a need for > as I use the employee lookup table for joins simply to grab metadata. > I have no need to act on employees as an object for CRUD purposes, and > see the added steps of getting an employee object and setting it as a > parent from the developer object as cumbersome. > > Am I approaching this scenario in the wrong fashion? Are there other > more elegant solutions that I haven't discovered? Any advice is > greatly appreciated! > > Thanks, > haylo > > > -- E: [email protected] W: www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
