Transfer: <property> and <manytoone> don't play well together
Posted by Russell Brown at 11:31 PM
2 comments - Categories: ColdFusion | Development | Transfer
Last week I started a new project and I decided to use Transfer-ORM. So far I've been happy with it's offerings aside from one severe headach my limited knowledge on the product has created. In my database I have multiple depths of linking, I would like to leverage the <manytoone> ability of Transfer, howevere I also need to use these same fields in a readByPropertyMap call.
My goal is to be able to use eventId as a property while being able to "getEvent()" and get back a transfer object. The Issue: You can't have the same a column in your config as is the link column in a <manytoone>. Transfer is nice enough to create the supporting methods for your linked tables/objects, but fails to give you a convenient way to "filter" by them. I feel this is an utmost basic use of object based design but I could be wrong.
The "Solution":
<object name="ObjectName" table="tblName">
<id name="sessionId" type="numeric" generate="false" />
<property name="eventIdLink" column="eventId" type="numeric" ignore-insert="true" />
<manytoone name="Event">
<link to="events.Event" column="eventId"/>
</manytoone>
</object>
- I appended "Link" to my property name. This is how it needs to be referenced in the readByPropertyMap()
- Added ignore-insert="true" to my properties
- renamed my nodes to the Object of what is returned.
I really think that if I should be ably to have a <property> named eventId and a <manytoone> named event on column eventId and have the app just know not to try and build 2 setEventId methods. Hopefully this will save someone else a few minutes time in their playing with Transfer...
Mark Mandel wrote on 06/18/08 1:49 AM
I would actually advocate against this approach (while it works), as you are exposing your relational model to your object model - which, quite frankly, is not what we are trying to achieve.
If you are looking to do read/list queries based on relationships, that is what TQL is for - to allow you to query against the object model configuration.
Once the configuration is done, you should be (mostly) only concerned with what our Object model is, because the relational side of things is handled for you.
That all being said, an interesting approach to the problem. I hadn't thought of using ignore-insert and ignore-update that way.