ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aliaksandr Radzivanovich <aliaksandr.radzivanov...@gmail.com>
Subject Re: Custom property editor?
Date Fri, 26 Nov 2004 13:21:39 GMT
My opinion is that it would be nice to have a way to provide
alternative view of a bean for the mapping framework. 'Alternative'
means that bean's properties would behave different when they are
being written to or loaded from a database. I'm going to do it by
subclassing the original beans and overriding their properties and
introducing new ones.


public class Company {
    public Company() {}
    public Company(Company src) { ... }
    public Calendar getLastModifiedTime() { ... };

public class CompanySql extends Company {
    public CompanySql(Company src) { super(src); ... }
    public Company asCompany() { return new Company(this); }
    public Date getLastModifiedTimeSql { ... }

<insert id="insertCompany" parameterClass="CompanySql">
    INSERT INTO Company (...)VALUES(... #lastModifiedTimeSql#)

public void insertCompany(Company company)
        throws DataAccessException {
        insert("insertCompany", new CompanySql(company));

public Company getCompany(int id)
        throws DataAccessException {
    return ((CompanySql) getSqlMapClientTemplate().
        queryForObject("getCompany", new Integer(id))).asCompany();

Can this problem be solved on the framework level? Or do I have to
write custom beans every time? Any thoughts, anybody?

On Thu, 25 Nov 2004 11:13:43 +0000, Kris Jenkins
<krisajenkins@yahoo.co.uk> wrote:
> Aliaksandr Radzivanovich wrote:
> >Thanks Kris, I've already found this class. My problem is that in some
> >cases it's a bit cumbersome to deal with type handlers in XML mapping
> >file.
> >It's not a problem for result maps, for example:
> ><resultMap id="personResult" class="person">
> >   <result property="birthDate" column="BirthDate" typeHandler="thDate"/>
> >Once described this result map can be used for any number of queries.
> >But to apply type handler to a parameter (not a result) I have to use
> >parameter map, or I have to specify
> >#parameterName,typeHandler=typeHandlerName#
> >for every mapped bean property like in the following example.
> >INSERT INTO Person (ID, …, BirthDate)
> >VALUES (#id#, …, #birthDate,typeHandler=thDate#)
> >When using parameter map it is impossible to use bean property names,
> >only their indices. So mapping and statement would look like
> ><parameterMap id="personParam" class="person">
> >   <parameter property="id"/>
> >   ...
> >   <parameter property="birthDate" typeHandler="thDate"/>
> >INSERT INTO Person (ID, …, BirthDate)
> >VALUES (?, …, ?)
> >Thus, for every single insert or update statement I have to provide
> >its own unique parameter map, or I have to specify type handler for
> >the same property in every update statement.
> >Am I right in my assumption?
> >So my suggestion is: it would be nice to create one general parameter
> >map and then using it with any number update statements providing bean
> >property names instead of their indices. Is this possible?
> >Your help will be appreciated.
> >
> >
> I believe you're right - you'll have to specify the typeHandler in every
> place that you use the property.
> As for your suggestion, we'll have to farm this out to Clinton et. al.,
> but it strikes me as messy.  Here's my alternative suggestion
> (shamelessly lifted from Spring 's Validator interface) - add a new
> method to TypeHandlerCallback:
>     /** Returns true if this typehandler supports the given class. */
>     boolean supports( Class clazz );
> For a property with a non-standard javaType, SqlMap would transparently
> use the first registered TypeHandler that claims to support the
> property's class.
> Perhaps SqlMap would consult these /before/ the standard typehandlers,
> which would give people the possibility of overriding the default
> handling, too.
> Any thoughts, anybody?
> --
> Kris Jenkins
> Email:  kris@jenkster.com
> Blog:   http://cafe.jenkster.com/
> Wiki:   http://wiki.jenkster.com/

View raw message