Makes sense, I'll have a go at that angle. Thanks for the feedback. On May 28, 4:28 pm, Mark Mandel <mark.man...@gmail.com> wrote: > 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 <hayl...@gmail.com> 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 <mark.man...@gmail.com> 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 <hayl...@gmail.com> 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: mark.man...@gmail.com > > > W:www.compoundtheory.com > > -- > E: mark.man...@gmail.com > 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 transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
