Comments inline. Overall, you seem to have made this much more
complicated than it needs to be. Looking at your database schema from
your original message, all the table columns are simple strings or
number, except for the gender enum. But you've elected to make every
column a distinct object type. That is why your solution is more
complex than you might wish.
Because you've elected to transform every column into a distinct object
type, you have to tell iBATIS what those object types are. It can't
possibly guess at such things. And that is why you are having to
specify all the javaType's. If you would have used simple strings and
numbers, you would not have to do so.
On 1/2/2010 5:51 PM, Dan Forward wrote:
Thank you, Guy, you have been a big help!
This is what I came up with. It works, but not as well as I had hoped.
<resultMap type="User" id="userMap">
<constructor>
<idArg column="id" javaType="UserID"
typeHandler="UserIDHandler"/>
<arg column="gender" javaType="Gender"
typeHandler="GenderHandler"/>
<arg column="email" javaType="EmailAddress"
typeHandler="EmailAddressHandler"/>
<arg column="phone" javaType="TelephoneNumber"
typeHandler="TelephoneNumberHandler"/>
<arg column="birth_date" javaType="LocalDate"
typeHandler="LocalDateHandler"/>
<arg column="password_hash" javaType="SHA1"
typeHandler="SHA1Handler"/>
<arg column="avatar_id" javaType="StaticFileID"
typeHandler="StaticFileIDHandler"/>
<arg column="organization_id" javaType="OrganizationID"
typeHandler="OrganizationIDHandler"/>
<arg column="version" javaType="int"/>
</constructor>
<association property="name" javaType="Name">
<constructor>
<arg column="first_name" javaType="String"/>
<arg column="middle_name" javaType="String"/>
<arg column="last_name" javaType="String"/>
<arg column="suffix" javaType="String"/>
</constructor>
</association>
</resultMap>
I was surprised that I had to specify the javaType for every parameter.
Otherwise, iBATIS treated everything as an Object and could not find a
corresponding constructor. I then discovered that iBATIS was looking for an
Integer argument for the version even though I specified the javaType to be
an int. Finally, I had to remove name from the constructor since constructor
tags do not support child association tags.
Already discussed the need for all the javaType's. I don't know about
the int; I've used them successfully without issue. I don't understand
what you mean by "I had to remove name from the constructor"; I don't
see a column called "name" in your table.
As a side note, I try to follow the recommendation by Joshua Bloch in
Effective Java to use static factory methods instead of constructors, so I
only have private constructors. I used DefaultObjectFactory as a model to
create my own ObjectFactory that first looks for a matching static factory
method before looking for a constructor.
I just use JavaBeans instead of trying to do all the data filling from
the constructor. iBATIS will use the empty constructor automatically.
Any particular reason you want to do the data assignments via constructors?
One of the reasons I chose iBATIS was that Hibernate put too many
constraints on my domain model. It isn't really a POJO if you say it has to
have a public constructor, an empty constructor, and setters for every
property. iBATIS is less strict, but still has some hoops to jump through.
Wouldn't it be nice to have a persistence layer that transparently
accommodated the domain model? What if I wanted to use a separate Factory
class to create my User objects?
Look at page 14 in the documentation. You can supply your own
ObjectFactory.
As you've discovered, no persistence layer is perfect. Unless you write
your own, every pre-packaged persistence approach will have some
compromises in order to appeal to a significantly large audience.
If you Google, you'll find several articles comparing Hibernate, JPA and
iBATIS. If you are starting from scratch and have complete control over
both your database implementation and your Java frameworks, then
something like Hibernate might be appropriate. In our situation, we
have a pre-existing, not-well-normalized database; iBATIS removes all
the grunt work but still allows us complete control over how we access
our data.
--
Guy Rouillier
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
For additional commands, e-mail: user-java-h...@ibatis.apache.org
