ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From I L <iss...@hotmail.com>
Subject RE: IBatis 3 backward compatibility
Date Mon, 24 Aug 2009 07:41:22 GMT

created JIRA ticket at https://issues.apache.org/jira/browse/IBATIS-628

Has a surprising twist :)

Cheers!

Date: Sun, 23 Aug 2009 22:57:04 -0600
Subject: Re: IBatis 3 backward compatibility
From: clinton.begin@gmail.com
To: user-java@ibatis.apache.org

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

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.





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. Find
out more.




With Windows Live, you can organize, edit, and share your photos. Click here.


_________________________________________________________________
Get back to school stuff for them and cashback for you.
http://www.bing.com/cashback?form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB_BackToSchool_Cashback_BTSCashback_1x1
Mime
View raw message