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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
