Javalobby and dzone and devx.com do iBATIS...
This just arrived in my inbox...my regular JavaLobby newsletter. I couldn't find an online version, so I'm posting it here and will add it to the wiki.After at least three months of on and off work, we are pleased to say that dzone.com is finally ready for you to enjoy. (Be sure to read Matt's column following this one for some detailed tips and insights about how to get the most from dzone.com[snip]That being said, we feel good about what we built to power dzone.com. To begin with, we used Spring 2.0 and the Spring Web MVC, [snip] But the more interesting technical choice was probably the selection of Apache iBatis for data persistence. One of the great advantages of Spring is that it makes it easy to support replaceable implementations for your data persistence. Hibernate, of course, is a very popular choice and works well with Spring. We were concerned, however, that with Hibernate we would be relying too heavily of the ORM layer to perform database magic. Having learned from hard experience that database optimization can have at least as much, if not more, impact on overall performance of Java web applications, we thought it might be prudent to stay a little closer to our SQL than Hibernate makes it easy to do. Now don't get me wrong, we have used Hibernate with great success in other applications, and Matt and I both respect and admire what this excellent open source ORM layer gives you. We have also spen! t more than a few hours watching database logs to find problems in Hibernate applications, and the SQL Hibernate generates can be really scary. It's almost invariably correct, but it has that machine-like bias for not caring whether the queries it outputs are human-readable. iBatis, on the other hand, allowed us to enjoy many of the advantages of an ORM layer without handing over control to a black box, even one as competent as Hibernate obviously is. We got to construct hand-written SQL for our operations and correlate the results of those SQL statements with JavaBeans that provide object-oriented mappings to and from the database backend. Spring was equally well prepared to work with iBatis as it was with Hibernate, so we had confidence that we could drop back to Hibernate if our iBatis experiment didn't work out. It did work out, however. iBatis lets us stay very close to the database, almost as if we were using direct JDBC calls, yet we get to concentrate all of those calls behind a JavaBeans abstraction that let us build DAOs, managers and work in a thoroughly object-oriented data model without concern for the relational database behind it. iBatis was a good choice for dzone.com, and I'm! glad we took the chance to try it out. It's just one more case that proves there is more than one way to get the job done well. Hibernate is extremely popular, but there are other excellent options out there, too.---dzone.com looks great, and JavaLobby also has a new look and feel (since the last time I was there anyway). Check them out.Also a link on dzone found me this: http://www.devx.com/Java/Article/31481?trk=DXRSS_LATESTCheers,Clinton
[jira] Closed: (IBATIS-282) truncation of date property values in the presence of dynamic sql
[ http://issues.apache.org/jira/browse/IBATIS-282?page=all ] Jeff Butler closed IBATIS-282: -- Resolution: Cannot Reproduce As discussed in the comments, I cannot repeat this behavior. Everything seems to work as expected. Feel free to reopen if you can provide a repeatable test case. > truncation of date property values in the presence of dynamic sql > - > > Key: IBATIS-282 > URL: http://issues.apache.org/jira/browse/IBATIS-282 > Project: iBatis for Java > Type: Bug > Components: SQL Maps > Versions: 2.1.7 > Environment: linux, mysql, java 1.5 > Reporter: z. zhong > Attachments: test.zip > > strange interaction between Java.util.Date parameters and dynamic sql. > query 1: > select > ... > where > ... > and rd.event_time <= #endTime# > the generated SQL is > ... > and rd.event_time <= '2006-03-30 18:33:46' > > so far so good. > query 2: > just add an extra dynamic sql at the end: > select > ... > where > ... > and rd.event_time <= #endTime# > #done[]# > > and the SQL becomes > ... > and rd.event_time <= '2006-03-30' > and ... > The date value has been truncated. > Notes: > * i've tried other dynamic sql elements: isNotEmpty, etc., and got the same > problem. > * insert seems to work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-129) Middlegen plugin for iBatis
[ http://issues.apache.org/jira/browse/IBATIS-129?page=all ] Jeff Butler closed IBATIS-129: -- Resolution: Invalid This isn't really a bug - its more of an announcement. Any announcement of progress on the tool is welcome on the users list, and you can always add information and links on the WIKI. Thanks for supporting iBATIS! > Middlegen plugin for iBatis > --- > > Key: IBATIS-129 > URL: http://issues.apache.org/jira/browse/IBATIS-129 > Project: iBatis for Java > Type: Wish > Components: SQL Maps > Versions: 2.0.8, 2.0.9, 2.1.0, 2.0.9b > Reporter: Philippe Mouawad > > I've developped a basic plugin for iBatis persistence layer that generates > - Mapping XML file : SELECT BY PK/INSERT/UPDATE/DELETE and ResultMap > - Java Bean > If you're interested, you can get the source code at the RFE section with id > 1202421 on middlegen sourceforge project: > http://sourceforge.net/tracker/index.php?func=detail&aid=1202421&group_id=36044&atid=415993 > Philippe > Ubik-Ingenierie -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (IBATIS-50) Ability to override the default bean creation mechanism
[ http://issues.apache.org/jira/browse/IBATIS-50?page=all ]
Jeff Butler closed IBATIS-50:
-
Fix Version: 2.2.0
Resolution: Fixed
Fixed (and documented) in SVN.
> Ability to override the default bean creation mechanism
> ---
>
> Key: IBATIS-50
> URL: http://issues.apache.org/jira/browse/IBATIS-50
> Project: iBatis for Java
> Type: Wish
> Components: SQL Maps
> Versions: 2.0.9
> Reporter: Philippe Laflamme
> Assignee: Jeff Butler
> Fix For: 2.2.0
>
> Currently, iBatis is responsible for creating instances of classes used in
> result maps. It relies on the assumption that objects can be obtained using
> the Class.newInstance() method (or something equivalent).
> The assumption forces users of the framework to create classes with a no-arg
> default constructor. IMHO, this also has the effect of favoring
> implementation inheritance (extends) over interface inheritance.
> Although this is not a problem in most cases, the ability to plug in an
> external instance factory would provide more flexibility and favor good
> programming practices. Amongst other things, it would provide developers the
> ability write code in terms of interface.
> A simple solution is to provide an extension point where resultMap class
> instances are obtained from.
> The simplest form would be:
> public interface InstanceFactory {
> Object createInstance(Class resultMapClass);
> }
> The default implementation would do something along the lines of:
> [...]
> return resultMapClass.newInstance();
> [...]
> Developers could configure iBatis to either use the default implementation or
> their own custom implementation. The setting could be part of the
> sqlMapConfig file or even per resultMap.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-303) SqlMapExecutor.executeBatch() returns 0
[
http://issues.apache.org/jira/browse/IBATIS-303?page=comments#action_12415157 ]
Sven Boden commented on IBATIS-303:
---
I would suggest to take this to the iBATIS development list, this is more a
support problem not an iBATIS issue. I will close this JIRA shortly as
"invalid".
You've answered you're own problem... use transactions. Something as:
try {
sqlMaps.startTransaction();
sqlMap.startBatch();
// map stuff
Map args = CollectionUtil.createMap(2);
for(int i=0;i SqlMapExecutor.executeBatch() returns 0
> ---
>
> Key: IBATIS-303
> URL: http://issues.apache.org/jira/browse/IBATIS-303
> Project: iBatis for Java
> Type: Bug
> Components: SQL Maps
> Versions: 2.1.7
> Environment: Oracle 9, OCI driver
> Reporter: george apostolov
>
> SqlMapExecutor.executeBatch() returns 0 on Oracle 9 using the oci jdbc driver.
> I saw someone had the same issue before but this still seems to be a problem
> Thanks,
> George
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-303) SqlMapExecutor.executeBatch() returns 0
[ http://issues.apache.org/jira/browse/IBATIS-303?page=comments#action_12415138 ] george apostolov commented on IBATIS-303: - I ran startBatch() - executeBatch() combination without transactions, so I could check the DB after each insert. It turns out that each insert makes it to the DB right away, i.e. the startBatch had no effect. In this case executeBatch returning 0 seems ok and the real problem is that there is no batching happening at all. > SqlMapExecutor.executeBatch() returns 0 > --- > > Key: IBATIS-303 > URL: http://issues.apache.org/jira/browse/IBATIS-303 > Project: iBatis for Java > Type: Bug > Components: SQL Maps > Versions: 2.1.7 > Environment: Oracle 9, OCI driver > Reporter: george apostolov > > SqlMapExecutor.executeBatch() returns 0 on Oracle 9 using the oci jdbc driver. > I saw someone had the same issue before but this still seems to be a problem > Thanks, > George -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-303) SqlMapExecutor.executeBatch() returns 0
[ http://issues.apache.org/jira/browse/IBATIS-303?page=comments#action_12415107 ] Sven Boden commented on IBATIS-303: --- It's a known problem, and it's not going to be solved. It's not in iBATIS, it's a problem with Oracle's driver. The JDBC spec allows vendors to skip certain functionality in executeBatch and this is what Oracle does, they return -2 for updates in executeBatch which iBATIS translates to 0. Oracle just doesn't return the number of rows being updated for prepared statements. >From the Oracle 9i documentation: "For a prepared statement batch, it is not >possible to know the number of rows affected in the database by each >individual statement in the batch. Therefore, all array elements have a value >of -2. According to the JDBC 2.0 specification, a value of -2 indicates that >the operation was successful but the number of rows affected is unknown." > SqlMapExecutor.executeBatch() returns 0 > --- > > Key: IBATIS-303 > URL: http://issues.apache.org/jira/browse/IBATIS-303 > Project: iBatis for Java > Type: Bug > Components: SQL Maps > Versions: 2.1.7 > Environment: Oracle 9, OCI driver > Reporter: george apostolov > > SqlMapExecutor.executeBatch() returns 0 on Oracle 9 using the oci jdbc driver. > I saw someone had the same issue before but this still seems to be a problem > Thanks, > George -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
