Clinton,
You are correct. After more testing, the mysql driver I am using is returning
the same value for both
getColumnLabel() and getColumnName(). Both did not return the table prefix.
However, I have another project running ibatis2 that is using the table prefix
syntax with no issues (e.g. column="user.version"). The bindings are actually
working.
Does Ibatis2 execute some sort of discovery algorithm that ibatis3 does not?
Like maybe removing the table prefix before parsing? I am digging through
ibatis2 code with no luck. As this is the first time I am looking at the code,
things are looking like Chinese to me.
Thanks for your help!
Date: Sun, 23 Aug 2009 13:52:05 -0600
Subject: Re: IBatis 3 backward compatibility
From: clinton.be...@gmail.com
To: user-java@ibatis.apache.org
Scenario 1 is entirely dependent upon your RDBMS and your JDBC driver... I
don't believe it works in iBATIS 2 either. Most JDBC drivers seem to strip the
table prefix from the column name. So unfortunately, column aliases are your
only hope there.
If you find a JDBC driver that works differently (either for the column name or
label) I'd love to know, just in case there is a flag or something we can use.
I'll look into Scenario 2 and respond in the JIRA ticket.
Clinton
On Sat, Aug 22, 2009 at 9:10 PM, I L <iss...@hotmail.com> wrote:
Created Jira Ticket with failing JUnit: IBATIS-627
Date: Sat, 22 Aug 2009 19:38:09 -0600
Subject: Re: IBatis 3 backward compatibility
From: clinton.be...@gmail.com
To: user-java@ibatis.apache.org
That's very strange... iBATIS 2 and 3 shouldn't differ in any way there...
Clinton
On Sat, Aug 22, 2009 at 7:32 PM, I L <iss...@hotmail.com> wrote:
Clinton,
for Scenario 1, I toggled useColumnLabel to true and false with no luck.
<setting name="useColumnLabel" value="true"/>
If I use user.version instead of just version, I get a null back. Any other
ideas?
For scenario 2, I will try to get a JUnit for ya in the next hour.
Cheers!
Date: Sat, 22 Aug 2009 18:44:54 -0600
Subject: Re: IBatis 3 backward compatibility
From: clinton.be...@gmail.com
To: user-java@ibatis.apache.org
The first is probably a column name vs. column label issue. There's a setting
for that in the Configuration class and the settings element in XML (I believe
it's called useColumnLabels="true"). iBATIS doesn't do anything special there,
but the label vs. column default may have changed.
The second case might be a bug, but I'm sure there's a unit test that covers
that scenario ... I'll check into it. In the mean time, if you could create a
JIRA ticket and attach a failing unit test, that would rock.
Cheers,
Clinton
On Sat, Aug 22, 2009 at 5:57 PM, I L <iss...@hotmail.com> wrote:
This is the exception I am getting for scenario 2:
### Error querying database. Cause:
org.apache.ibatis.executor.ExecutorException: No type handler could be found to
map the property 'password' to the column 'PASSWORD'. One or both of the
types, or the combination of types is not supported.
### The error may exist in com/test/test/db/config/User.xml
### The error may involve User.UserResult
### The error occurred while handling result set
### SQL: SELECT * FROM user WHERE oid = ?
### Cause: org.apache.ibatis.executor.ExecutorException: No type handler could
be found to map the property 'password' to the column 'PASSWORD'. One or both
of the types, or the combination of types is not supported.
org.apache.ibatis.exceptions.IbatisException:
### Error querying database. Cause:
org.apache.ibatis.executor.ExecutorException: No type handler could be found to
map the property 'password' to the column 'PASSWORD'. One or both of the
types, or the combination of types is not supported.
### The error may exist in com/test/test/db/config/User.xml
### The error may involve User.UserResult
### The error occurred while handling result set
### SQL: SELECT * FROM user WHERE oid = ?
### Cause: org.apache.ibatis.executor.ExecutorException: No type handler could
be found to map the property 'password' to the column 'PASSWORD'. One or both
of the types, or the combination of types is not supported.
at
org.apache.ibatis.exceptions.ExceptionFactory.wrapException(ExceptionFactory.java:8)
at
org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:52)
at
org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:44)
at
org.apache.ibatis.session.defaults.DefaultSqlSession.selectOne(DefaultSqlSession.java:32)
From: iss...@hotmail.com
To: user-java@ibatis.apache.org
Subject: IBatis 3 backward compatibility
Date: Sat, 22 Aug 2009 23:47:07 +0000
Hi,
I found two scenario's in which used to work in ibatis 2 but no longer works in
ibatis 3.
Scenario 1:
In ibatis 2, you could specify the table name and column name:
e.g.
<result column="user.version" jdbcType="INTEGER" property="version" />
In this case the table is "user" and the column is "version"
With Ibatis 3, if I specify the full column name, "user.version", pojo binding
doesn't occur. I must omit the "user." part to just
<result column="version" jdbcType="INTEGER" property="version" />
The ability to have the fully qualified column name is important when you need
to distinguish them when both columns are selected from the database.
e.g.
<result column="user.version" jdbcType="INTEGER" property="version" />
<result column="place.version" jdbcType="INTEGER" property="version" />
Of course there I could change the column names so they are unique across all
tables or use aliasing when necessary. But I thought the ibatis 2 approach was
cleaner
Scenario 2:
In ibatis 2, I used to be able to access a pojo property that is complex:
e.g.
<result column="password" property="password.encrypted" jdbcType="VARCHAR" />
So I had a Field of type Password which had and encrypted member. I only want
to persist "encrypted"
class Pojo{
private Password password;
}
class Password{
private String encrypted; //the encrypted string
public void getDecryptedString(){...}
}
Windows Live: Make it easier for your friends to see what you’re up to on
Facebook. Find out more.
Hotmail® is up to 70% faster. Now good news travels really fast. Try it now.
Windows Live: Keep your friends up to date with what you do online. Find out
more.
Windows Live: Make it easier for your friends to see what you’re up to on
Facebook. Find out more.
_________________________________________________________________
Windows Live: Make it easier for your friends to see what you’re up to on
Facebook.
http://windowslive.com/Campaign/SocialNetworking?ocid=PID23285::T:WLMTAGL:ON:WL:en-US:SI_SB_facebook:082009
