Sure, that will help. Can you use HSQLDB instead of MySQL? That way I can include it in the iB3 test if possible.
I can't imagine how it's working in iB2... LOL... I suppose I should be able to at least guess. :-) Cheers, Clinton On Sun, Aug 23, 2009 at 10:40 PM, I L <iss...@hotmail.com> wrote: > Hi Clinton, > > First of all, thank you for your help on this. > > I am not seeing a table prefix at all from the result set as you've > confirmed. But what baffles me is why the binding works in ibatis2 and not 3 > if I use table prefixes in the result maps. At this stage the best I can do > is create a JUnit that shows that table prefixing working in IBatis2 and Not > 3. Would that be of any help to figure it out? > > ------------------------------ > Date: Sun, 23 Aug 2009 21:16:57 -0600 > > Subject: Re: IBatis 3 backward compatibility > From: clinton.be...@gmail.com > To: user-java@ibatis.apache.org > > 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> > > > > ------------------------------ > With Windows Live, you can organize, edit, and share your photos. Click > here. <http://www.windowslive.com/Desktop/PhotoGallery> >
