Yes, the composite id would be dependent on the object model... but that's kinda the point of ORM, it gives you an object model to work with, not a relational model.
Mark On Fri, May 29, 2009 at 1:37 AM, Kerr <[email protected]> wrote: > > Mark, > > Thanks for your reply. Along the way, I did try the <manytoone> > technique you mention, and I noticed that a generated method named > setEmp is created. If I follow this logic correctly, I would still > need to create/get an employee object with the employee's ID, and then > use setEmp to set the employee's ID. Am I correct in this thought? I > was looking for a way around having to instantiate an employee object > while setting the various properties in the developer object, while > still utilizing the compositeid and manytoone relationship. > > On May 27, 6:13 pm, Mark Mandel <[email protected]> wrote: > > 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#com... > > > > 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 > > > -- 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 -~----------~----~----~----~------~----~------~--~---
