Thanks for your feedback Chris.
I should have applied my comment to all features....if you have a need, and fill it, feel free to contribute it back. After all, you're the best people to solve the problems! ;-)
Cheers,
Clinton
On 3/18/06, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:
I would disagree with not implementing IBATIS-22: Specify Query Timeout. This definitely something that is supported by the JDBC API (just not neceassarily every jdbc driver) and it is necessary for mission critical applications. We can't let a potential "run-away" query lock-up an entire application... this actually happened to us in a production environment and we made a change to the IBatis core to support this concept. Haven't gotten around to submitting it back yet...- Chris-----Original Message-----
From: Clinton Begin [mailto:[EMAIL PROTECTED]]
Sent: Saturday, March 18, 2006 12:05 PM
To: dev@ibatis.apache.org; [EMAIL PROTECTED]
Subject: Re: Maybe OT... what not to have in iBATIS
+1 on all accounts.
The only comment I'd have is about EHCache and JCS....iBATIS has a pluggable cache model, that should be compatible with either. Although Cameron Purdy once suggested we open up the CacheModel class for extension, to make integrating JCS (Coherence in his case). I think Cameron's idea is good, and I believe it's already logged in JIRA. We could add support for JCS or EHCache, but I'd suggest the people who want them should implement them and then contribute them to the project. I don't want to be an ivory tower of generating plugins for everything under the sun. By waiting for someone else to implement it, we're ensuring there's an audience for the feature.
In any case.....I say close 'em!
BTW: Great job triaging the issue tracker entries Sven!
Cheers,
Clinton
On 3/18/06, Sven Boden <[EMAIL PROTECTED]> wrote:
Do we ever vote on stuff we don't want to have in iBATIS?... Below is a
list of JIRA requests/bugs I would not implement.
Regards,
Sven
- IBATIS-22: Specify Query Timeout
The only projects I can think of that would need it would be kind of
reporting systems. Most systems I know of either want to have the or
data or not. Timeout is also not supported by JDBC and implementing a
hack for it (2 threads and then cancelling after the timeout) causes
problems in DB2 for sure (hanging connections). And a workaround exists
by using it via a Timeout aware datasource.
- IBATIS-73: EHCache for iBATIS
I would rather have JCS (http://jakarta.apache.org/jcs/index.html) as
cache then EHCache. JCS was written as a EHCache replacement. But maybe
we already have enough dependencies,
- IBATIS-119: use label from sql for mapping (XML stuff)
Doesn't seem very useful.
- IBATIS-120: Use of java.util.List for input parameter
Too error prone.
- IBATIS-206: Support for JDBC 3.0 Disconnected Resultsets such as
WebRowSet/CachedRowSet
iBATIS is into returning domain objects, not returning ResultSets
- IBATIS-211: Cache should follow structure of hierarchical resultmaps
As stated doesn't make sense as iBATIS doesn't use object identity...
something as flushOnFlush could possibly be implemented.
- IBATIS-222: Evict from cache
Could even be closed now... it doesn't make sense as iBATIS doesn't use
object identity
- IBATIS-226: Support Commons DBUtils ResultHandler
Not as in the original request. Could be implemented as some kind of
extension point
- IBATIS-240: Add support to generate either non-prepared statements or
sequence of simple SQL statements
including bad practices is not on my wishlist
- IBATIS-259: SqlMapTransactionManager.setUserConnection(null) does not
complete restore previous transaction state
Not the intended usage
**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************
