Hi Clinton,
I have been thinking about defined a sharding architecture for a while by
using iBatis. And I found if iBatis core lib could add some serveral more
methods, it would be more helpful. As following,
Object insert(String statementName, Object parameterObject, Object
sharding)
Object
Insert a proxy SqlMapClient implementation that does the wrapping for you.
Cheers,
Clinton
On Wed, Aug 6, 2008 at 12:09 AM, Jiming Liu [EMAIL PROTECTED] wrote:
Hi Clinton,
I have been thinking about defined a sharding architecture for a while by
using iBatis. And I found if iBatis core lib
Hi All,
We are using Spring 2.5.4 + iBATIS 2.3.2 as persistence solution of a
development framework. We managed to build a generic CRUD base
implementation to ease development. What we couldn't do is, get the updated
object as a result of update() method. Because update method returns an int
I still think add one more parameters is better. As using parameterClass as
a map will make the xml not as nifty as it was, comparing the second xml
part. But anyway, put more your energy in the more important features.
Really looking forward to the 3.0 release ...
Thanks a lot!
Jiming
Hello:
So, I have things up and running under Java and iBATIS, but running into
some starvation issue, and my server is locking up. When I dump threads,
I see a bunch that are waiting for the connnection pool (see output #1
below) and as well, a bunch that are waiting on Throttle.increment (see
Have a look at this thread:
http://www.mail-archive.com/user-java@ibatis.apache.org/msg11828.html
Good luck
On Wed, Aug 6, 2008 at 4:47 PM, Brian Parkinson [EMAIL PROTECTED] wrote:
Hello:
So, I have things up and running under Java and iBATIS, but running into
some starvation issue, and my
HI Nicholoz - looked at that thread - thx.
A key issue seems to be not closing connections, but my understanding is
that the DBCP connection pool handles all that for me (?).
The Dao implementation is pretty simple - I'm not explicitly declaring
transations, since using Spring transaction
Well just don't call it parameterObject ... param or even just p is
fine. It's not like it can be easily confused with anything else. :-)
Clinton
On Wed, Aug 6, 2008 at 4:31 AM, Jiming Liu [EMAIL PROTECTED] wrote:
I still think add one more parameters is better. As using parameterClass as
a
Pools handle closing connections, but you still have to call .close (or some
higher level delegating method) to return the connection to the pool. The
rules are always the same... if you open it / start it / retrieve it, then
you must close it / stop it / return it...
That said, upgrade to
HI Clinton:
Have upgraded, and am refactoring some of my iBATIS code. You write:
Pools handle closing connections, but you still have to call .close (or
some higher level delegating method) to return the connection to the
pool. The rules are always the same... if you open it / start it /
I would like to change the default column -- property name mapping
functionality.
eg in my db, column names are of the form column_name whereas properties
are of the form columnName
I have read through the documentation and there is no mention of providing
my own column -- property name mapper.
I have some columns in my db that are char instead of varchar and therefore
need trimming
I have therefore declared a typehandler for string
typeHandler javaType=java.lang.String
callback=foo.bar.StringTypeHandler/
The type handler works perfectly when populating a bean property but does
not get
Not sure I understand you. This is exactly how a resultMap works (and
core to iBATIS)
resultMap id=getPaymentResult class=payment
result property=paymentId column=PAYMENT_IDI/
On Aug 6, 2008, at 9:39 AM, Lance Java wrote:
I would like to change the default column --
Lance -
I'm pretty sure this is only a proposed feature for 3.0. Jason's example is
the only way of mapping columns to properties that I'm aware of in 2.x.
http://opensource.atlassian.com/confluence/oss/display/IBATIS/iBATIS+3.0+Whiteboard#iBATIS3.0Whiteboard-SomePossibleConfigurationOptions
Ah, if you're using Spring, then yes, it will take care of resource
allocation. But your statement was: but my understanding is that the DBCP
connection pool handles all that for me (?), which is not the case.
Clinton
On Wed, Aug 6, 2008 at 7:57 AM, Brian Parkinson [EMAIL PROTECTED] wrote:
HI
If you don't mind running a hacked version of the framework, you could hack
AutoResultMap.java.
Clinton
On Wed, Aug 6, 2008 at 9:11 AM, Michael Schall [EMAIL PROTECTED]wrote:
Lance -
I'm pretty sure this is only a proposed feature for 3.0. Jason's example
is the only way of mapping columns
PS: Make it configurable/pluggable and maybe we'll even include it. See
the iBATIS 3 wiki page for proposed requirements.
On Wed, Aug 6, 2008 at 9:17 AM, Clinton Begin [EMAIL PROTECTED]wrote:
If you don't mind running a hacked version of the framework, you could hack
AutoResultMap.java.
Yep, that's what I'm after.
A more generic solution would be to provide a mapper in the ibatis config
with:
getPropertyName(Class typeToPopulate, String columnName)
Jason, thanks for the response but I'm looking for something less verbose
and easier to maintain.
On 06/08/2008, Michael Schall
Hi Clinton -
Just for clarification
1. Using Spring for transactions means that my Dao method
implementartion can be simple (as example below) without
try/catch/finally blocks.
2. Using DBCP for connection pooling means that I don't have to
explictly release and connection resources.
Yes, those statements are technically correct. I look forward to seeing the
results of the new test.
Cheers,
Clinton
On Wed, Aug 6, 2008 at 9:21 AM, Brian Parkinson [EMAIL PROTECTED] wrote:
Hi Clinton -
Just for clarification
1. Using Spring for transactions means that my Dao method
Will it be possible to provide some pros and cons for the questions below:
1. If I were to use Hibernate 3.2 with Native SQL in several places of the
project (because the database is complex and I do not have control over it
as a Java developer), am I better off using iBATIS instead?
2. Will it
Hi ,
Hibernate and Ibatis comparison is like comparing apples and oranges.
Bothe serve different purposes. This is what I told folks at my company b4
we decided to go in with Ibatis instead of Hibernate.
Pros of Ibatis
===
1. Stored procedure support is out of the world.
2. Not pure
More pros:
* arbitrary mapping to non-bean/rich classes.. you can request primitives
or maps
* mapping the same tables to multiple classes and vice versa
* no assumptions about primary keys
In many cases you'll find you *can* do a lot of these things with Hibernate,
but it's more of a
If I may interject too...
You could use ibator to guickly generate a basic iBATIS based CRUD layer and
then just focus on the complex queries. This can give you some of the
productivity benefits of Hibernate, and still leave you free to code the
complex stuff in an efficient manner.
Jeff Butler
On Wed, Aug 6, 2008 at 9:02 PM, Jeff Butler [EMAIL PROTECTED] wrote:
If I may interject too...
You could use ibator to guickly generate a basic iBATIS based CRUD layer and
then just focus on the complex queries. This can give you some of the
productivity benefits of Hibernate, and still
for Hibernate 2, they had something called as hibernate tools(which
apparently had a eclipse plug-in too) which could generate xmls and bean
classes. Am not sure if there is an upgraded version for hibernate 3 to get
the annotations in place in the bean class.
On Wed, Aug 6, 2008 at 1:44 PM,
One thing you may consider ...
I have been happy with ibatis 90% of the time. However, I had no choice
but to convert good chunk of my project from ibatis to JDBC in the past
because of a memory leak issue. I've posed this question here in the
past but - here is the code that generated the
ok, thanks:)
On Wed, Aug 6, 2008 at 9:49 PM, Clinton Begin [EMAIL PROTECTED]wrote:
Well just don't call it parameterObject ... param or even just p is
fine. It's not like it can be easily confused with anything else. :-)
Clinton
On Wed, Aug 6, 2008 at 4:31 AM, Jiming Liu [EMAIL
Clinton,
A bit confused here (new to ibatis)...
The docs state: By default, calling any execute method on
SqlMapClient instance (e.g. queryForObject() or insert()) will auto-
commit or auto-rollback. This means that each call to any execution
method will be a single unit of work.
Also,
No, that would not be needed if you were making calls to iBATIS mapped
statements - they will manage the connections (and transactions) for
you.
Larry
On Wed, Aug 6, 2008 at 10:26 PM, Ian Zabel [EMAIL PROTECTED] wrote:
Clinton,
A bit confused here (new to ibatis)...
The docs state: By
It depends on the transaction manager and the datasource.
For example, with an EXTERNAL transaction manager and a user provided
connection (which overrides the datasource) like spring uses, Spring is
fully responsible for closing the connection. The one exception might be
for lazily loaded
31 matches
Mail list logo
