ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: IBatis 3 backward compatibility
Date Mon, 24 Aug 2009 04:57:04 GMT
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 <isster@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.begin@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 <isster@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.begin@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 <isster@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.begin@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 <isster@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.begin@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 <isster@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: isster@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>
>

Mime
View raw message