iBATIS doesn't do anything special in that regard. And if I remove iBATIS from the mix entirely, I can't even get JDBC to return the table prefix with either....
To be clear, there's a difference between an alias: SELECT id as "my_aliased_id"... And a table prefix: SELECT u.id FROM USER u... In the latter case, JDBC seems to only return "id" not "u.id", which seems to be consistent for years... are you seeing something different using rs.getXxxxx(colname)? Clinton On Sun, Aug 23, 2009 at 5:32 PM, I L <iss...@hotmail.com> wrote: > 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<https://issues.apache.org/jira/browse/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.<http://windowslive.com/Campaign/SocialNetworking?ocid=PID23285::T:WLMTAGL:ON:WL:en-US:SI_SB_facebook:082009> > ------------------------------ > Hotmail® is up to 70% faster. Now good news travels really fast. Try it > now.<http://windowslive.com/online/hotmail?ocid=PID23391::T:WLMTAGL:ON:WL:en-US:WM_HYGN_faster:082009> > > > > ------------------------------ > Windows Live: Keep your friends up to date with what you do online. Find > out > more.<http://windowslive.com/Campaign/SocialNetworking?ocid=PID23285::T:WLMTAGL:ON:WL:en-US:SI_SB_online:082009> > > > > ------------------------------ > Windows Live: Make it easier for your friends to see what you’re up to on > Facebook. Find out > more.<http://windowslive.com/Campaign/SocialNetworking?ocid=PID23285::T:WLMTAGL:ON:WL:en-US:SI_SB_facebook:082009> > > > > ------------------------------ > Windows Live: Make it easier for your friends to see what you’re up to on > Facebook. Find out > more.<http://windowslive.com/Campaign/SocialNetworking?ocid=PID23285::T:WLMTAGL:ON:WL:en-US:SI_SB_facebook:082009> >
