iBatis and ORM's

[Abdullah Kauchali]

So, iBatis is /not/ an ORM.

What makes Hibernate an ORM and iBatis not?

or a corollary:

What makes iBatis a DAO implementation and Hiberate not? (Is this a 
valid question, to

begin with?)

What are the /decisive/ qualities of each (viz. DAO vs ORM) that 
classify them appropriately?


I am looking for the mosst important /distinguishing/ (different) 
characteristics of each approach
so that when I now see a myriad of tools presented to me, I can say "ah, 
but this one does it

like this, so it /leans/ towards an ORM approach" ...

Kind regards

Abdullah

RE: paginated list

[Zsolt]

I use mysql-connector-java-3.1.11-bin.jar but it does also work with
mysql-connector-java-3.0.14-production.

log4j.logger.java.sql=DEBUG
log4j.logger.java.sql.Connection=DEBUG

Zsolt

>-Original Message-
>From: Eugeny N Dzhurinsky [mailto:[EMAIL PROTECTED]
>Sent: Friday, November 04, 2005 8:45 AM
>To: user-java@ibatis.apache.org
>Subject: Re: paginated list
>
>On Fri, Nov 04, 2005 at 08:22:29AM +0100, Zsolt wrote:
>> The MySql driver loads everything into the memory (unless you use LIMIT),
>> thus if paginated list just skips records it seems to be use less. Its
>> functionality can be replaced with List.subList(int fromIndex, int
>toIndex).
>>
>> My log just show java.sql.ResultSet returned by ibatis, and that contains
>> only a page. Are you sure that paginated list just skips records? In this
>> case we have to replace it because we work also on huge lists and cannot
>> load a couple of 100,000 records into memory to display for example 20.
>
>How did you configure logging to show java.sql.RusultSet statements?
>I tried to play with this for about 2 month, and all what I found is I need
>to
>provide
>log4j.logger.java.sql=DEBUG
>
>which will return everything logged by prepared statements and result sets,
>but it will not log anything in case if I specify
>log4j.logger.java.sql.PreparedStatement=DEBUG
>
>I'm using log4j 1.2.9 and iBATIS_DBL-2.1.5.582
>
>--
>Eugene N Dzhurinsky

Re: iBatis and ORM's

[Larry Meadors]

Man, this is a big one, and i am late already..i'll get it started.

The question is not DAO vs ORM, it is ORM vs Data Mapping.

ORM = mapping database objects to java objects (or c#, whatever).

Data mapping = mapping sql *statements* to java objects (c#, blah, whatever).

DAO can be used with either ORM or Data Mapping.

More later...

Larry


On 11/4/05, Abdullah Kauchali <[EMAIL PROTECTED]> wrote:
> So, iBatis is /not/ an ORM.
>
> What makes Hibernate an ORM and iBatis not?
>
> or a corollary:
>
> What makes iBatis a DAO implementation and Hiberate not? (Is this a
> valid question, to
> begin with?)
>
> What are the /decisive/ qualities of each (viz. DAO vs ORM) that
> classify them appropriately?
>
> I am looking for the mosst important /distinguishing/ (different)
> characteristics of each approach
> so that when I now see a myriad of tools presented to me, I can say "ah,
> but this one does it
> like this, so it /leans/ towards an ORM approach" ...
>
> Kind regards
>
> Abdullah
>
>

Re: iBatis and ORM's

[Clinton Begin]

Quick comparison...


ORM



1) Maps classes to tables, and columns to fields.

2) Must support Object Identity

3) Generates SQL



SQL Mapping



1) Maps objects (not necessarily a custom type, or even the same type) to statements

2) Generally does not support object identity (would be hard to do)

3) Allows complete hand coding of real SQL, with full support for nearly all RDBMS features



DAO

Irrelevant.  DAO is an abstraction pattern.  It serves a different design purpose entirely.



Cheers,

Clinton
On 11/4/05, Abdullah Kauchali <[EMAIL PROTECTED]> wrote:
So, iBatis is /not/ an ORM.What makes Hibernate an ORM and iBatis not?or a corollary:What makes iBatis a DAO implementation and Hiberate not? (Is this avalid question, tobegin with?)
What are the /decisive/ qualities of each (viz. DAO vs ORM) thatclassify them appropriately?I am looking for the mosst important /distinguishing/ (different)characteristics of each approachso that when I now see a myriad of tools presented to me, I can say "ah,
but this one does itlike this, so it /leans/ towards an ORM approach" ...Kind regardsAbdullah

Use isNull (in sqlMap) with a Long value?

[Steven Pannell]

Hi,

I want to make use of the isNull option in the sqlMap using a Long as the
parameter class like this:


UPDATE log
SET new = 

10


1000

where ID = #value#
   

But it does not work as I get the error java.lang.Long does not contain a
method value.

Anyone know how I can get this working?

thanks,
Steve

RE: Use isNull (in sqlMap) with a Long value?

[Niels Beekman]

I think you can leave out the property-attribute.

Niels

-Original Message-
From: Steven Pannell [mailto:[EMAIL PROTECTED] 
Sent: vrijdag 4 november 2005 17:05
To: user-java@ibatis.apache.org
Subject: Use isNull (in sqlMap) with a Long value?

Hi,

I want to make use of the isNull option in the sqlMap using a Long as
the
parameter class like this:


UPDATE log
SET new = 

10


1000

where ID = #value#
   

But it does not work as I get the error java.lang.Long does not contain
a
method value.

Anyone know how I can get this working?

thanks,
Steve

How to use nested "

[Zsolt]

Hi,

can somebody provide me how to use nested "

Re: How to use nested "

[Zarar Siddiqi]

Well, I've posted questions related to nested iterate tags before but with 
very limited responses.


Zsolt, I've tried using nested iterate tags but I've found that the property 
of the outer iterate tag doesn't seem to expand.  Here's the message I 
posted a while back and got no replies.  If anyone feels like giving their 
input, it would be appreciated.


I'm trying to do a search on some fields using keywords.  Both the keywords 
and the fields are being passed into the SQL Map but IBatis doesn't seem to 
expand the property specified in the outer iterate tag.  Both keywords and 
fields are of type java.util.List and contain java.lang.String objects.


   
   open="(" close=")">

  $fields[]$ LIKE '%$keywords[]$%'
   
   

When the above executes, I get the following error (it craps out when trying 
to get the value of keywords)


org.springframework.jdbc.UncategorizedSQLException: SqlMapClient operation; 
uncategorized SQLException for SQL []; SQL state [null]; error code [0];

--- The error occurred in com/xxx/xxx/xxx/SQLMap.xml.
--- The error occurred while preparing the mapped statement for execution.
--- Check the advancedSearchEndUsers.
--- Check the parameter map.
--- Cause: java.lang.NullPointerException; nested exception is 
com.ibatis.common.jdbc.exception.NestedSQLException:

--- The error occurred in com/xxx/xxx/xxx/xxx/SQLMap.xml.
--- The error occurred while preparing the mapped statement for execution.
--- Check the advancedSearchEndUsers.
--- Check the parameter map.
--- Cause: java.lang.NullPointerException
com.ibatis.common.jdbc.exception.NestedSQLException:
--- The error occurred in com/xxx/xxx/xxx/xxx/SQLMap.xml.
--- The error occurred while preparing the mapped statement for execution.
--- Check the advancedSearchEndUsers.
--- Check the parameter map.
--- Cause: java.lang.NullPointerException
Caused by: java.lang.NullPointerException
at 
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:188)
at 
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryForList(GeneralStatement.java:123)
at 
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForList(SqlMapExecutorDelegate.java:610)
at 
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForList(SqlMapSessionImpl.java:105)
at 
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryForList(SqlMapClientImpl.java:82)
at 
com.ibatis.sqlmap.engine.mapping.statement.PaginatedDataList.getList(PaginatedDataList.java:138)
at 
com.ibatis.sqlmap.engine.mapping.statement.PaginatedDataList.pageTo(PaginatedDataList.java:98)
at 
com.ibatis.sqlmap.engine.mapping.statement.PaginatedDataList.(PaginatedDataList.java:46)
at 
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForPaginatedList(SqlMapExecutorDelegate.java:667)
at 
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForPaginatedList(SqlMapSessionImpl.java:109)


For testing purposes, I then made fields the property of the outer loop and 
keywords the property of the inner loop.  This resulted in it crapping out 
when trying to get the value of fields.


Any ideas?






- Original Message - 
From: "Zsolt" <[EMAIL PROTECTED]>

To: 
Sent: Friday, November 04, 2005 12:05 PM
Subject: How to use nested "
Hi,

can somebody provide me how to use nested "

[OT ANN] Roomity v 1.5 w/ video, social networking and html editor + JDNC article

[netsql]

Roomity.com v 1.5 is a web 2.01/RiA poster child community webapp. This new version ads broadcast video, social networking such as favorite authors and html editor.It likely already has groups and content you are already using but aggregated and safer, including technology, Java, etc., but it only works on broadband. You can get to ibatis mail list via http://ibatis.roomity.com (and happens to use iBatis ;-) itself.V--iBatis_for_Java_Users_List.roomity.comYour Roomity Broadband Webapp ~~1131125637636~~--

Property starting with 'i' character in Turkish Locale

[Bahri Gencsoy]

 
Think about the most simple database table, just containing ID column as an integer:
 

CREATE TABLE SAMPLE(ID INTEGER NOT NULL PRIMARY KEY)
 
And very simple mapping configuration, as stated in the tutorial:
 

PUBLIC "-//iBATIS.com//DTD SQL Map 2.0//EN""
http://www.ibatis.com/dtd/sql-map-2.dtd">SELECTID as idWHERE ID = #value#
 
And 'Sample' bean with "getId()" and "setId(int i)" methods.

 
All the other configurations are handled as needed. The problem is, the returned object's "id" property is never set in Turkish locale! It is easy to regenerate:
 

Locale.setDefault(new Locale("tr")); //if you change this with "en", it works!
Sample sample = (Sample) map.queryForObject("getSample", new Integer(3));System.out.println(sample.getId()); //0 value, instead of 3
 
It just works fine if you change locale to "en", but not acceptable for me!!! And I don't want to change & switchback locale everytime.
 
'i' is a special character in Turkish, unlike the other latin languages, capital 'i' is 'İ' for Turkish, not 'I'. (I am not sure if you will see the difference in the mail, 'I' with a dot above it-can not remember the technical name). I tried to track the problem for 2 hours, but little success. I think the problem is in mapping from XML to property names, since I have seen that (while debugging) reflection for bean gives correct property names (in 
com.ibatis.common.beans.ClassInfo class's addMethods() method).
 
I'm using hsqldb 1.8.0.1 and ibatis 2.1.5 (latest versions up to date)
 
 
Any advice?
 
Thanks in advance,
Bahri GENCSOY
 

Same table, multiple sources

[Voorhoeve, Niels {PBG}]

Hi,

I have a situation where I need to read the same table from a couple of
different servers.  I'm using the ibatis dao framework on top of ibatis
sqlmaps.  I've thought of a couple of solutions and was wondering what the
best practice is?

1.  
a. Copy the sqlmap config file for the table to a new name.
b. Create another Dao class and context to use the new file.

2.
a. Create a second instance of a DaoManager from a second
dao-config.xml which reuses the same dao class and table.


It would be nice if the daoManager had a feature to specify the context to
use so that the above wouldn't be necessary.  Would it be feasible to add
such a feature?  

I guess it would look something like:
dao-config.xml:

...


daoManager.getDao(SomeBean.class, "this.server");

Thanks,
Niels

Re: Same table, multiple sources

[Larry Meadors]

Uhm, that is already available. ;-)

public Dao getDao(Class iface, String contextId);

...
...

Larry


On 11/4/05, Voorhoeve, Niels {PBG} <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have a situation where I need to read the same table from a couple of
> different servers.  I'm using the ibatis dao framework on top of ibatis
> sqlmaps.  I've thought of a couple of solutions and was wondering what the
> best practice is?
>
> 1.
> a. Copy the sqlmap config file for the table to a new name.
> b. Create another Dao class and context to use the new file.
>
> 2.
> a. Create a second instance of a DaoManager from a second
> dao-config.xml which reuses the same dao class and table.
>
>
> It would be nice if the daoManager had a feature to specify the context to
> use so that the above wouldn't be necessary.  Would it be feasible to add
> such a feature?
>
> I guess it would look something like:
> dao-config.xml:
> 
> ...
> 
>
> daoManager.getDao(SomeBean.class, "this.server");
>
> Thanks,
> Niels
>

Property starting with 'i' character in Turkish Locale

[Bahri Gencsoy]

 

Think about the most simple database table, just containing ID column
as an integer:





 







CREATE TABLE SAMPLE(ID INTEGER NOT NULL PRIMARY KEY)







 





And very simple mapping configuration, as stated in the tutorial:





 









PUBLIC "-//iBATIS.com//DTD SQL Map 2.0//EN"
" http://www.ibatis.com/dtd/sql-map-2.dtd">


SELECT
ID as id
WHERE ID = #value#









 





And 'Sample' bean with
"getId()"
and "setId(int
i)" methods. 





 





All the other configurations are handled as needed. The problem is, the
returned object's "id" property is never set in Turkish locale! It is
easy to regenerate:





 







Locale.setDefault(new Locale("tr")); //if
you change this with "en", it works!





Sample sample = (Sample) map.queryForObject("getSample",
new Integer(3));
System.out.println(sample.getId()); //0 value, instead of 3







 





It just works fine if you change locale to "en", but not
acceptable for me!!! And I don't want to change & switchback locale
everytime.





 





'i' is a special character in Turkish, unlike the other latin
languages, capital 'i' is 'İ' for Turkish, not 'I'. (I am not sure if you will
see the difference in the mail, 'I' with a dot above it-can not remember the
technical name). I tried to track the problem for 2 hours, but little success.
I think the problem is in mapping from XML to property names, since I have seen
that (while debugging) reflection for bean gives correct property names (in
com.ibatis.common.beans.ClassInfo class's addMethods() method).





 





I'm using hsqldb 1.8.0.1
and ibatis 2.1.5 (latest versions up to date)





 





 





Any advice?





 





Thanks in advance,





Bahri GENCSOY





 

Re: iBatis and ORM's

[Abdullah Kauchali]

Fantastic.  Some more questions in-line.  


Clinton Begin wrote:


ORM

1) Maps classes to tables, and columns to fields.


Don't we do that with iBatis too?   Are we saying that mapping classes 
to tables, and columns to

fields is generally a bad idea?


2) Must support Object Identity


Yes, of course.  Excellent point, thanks!


3) Generates SQL


Agreed.  But tools like Hibernate allow for adhoc queries.  Could the 
fact that this "escape hatch"
(to allow for ad hoc or "hand written" queries) be taken as an argument 
that such tools are in fact
exactly like iBatis but with /more/ features?  (Did I phrase that 
right?)  I guess, what I really want to
ask is:  what is the trade-off or compromise in the design when 
Hibernate users begin to use the

ad hoc query facilty?  (There has to be a cost!  :-)  )



SQL Mapping

1) Maps objects (not necessarily a custom type, or even the same type) 
to statements


Clinton, I am trying to understand this carefully.  Don't you mean "map 
objects to rows of a resultset

created from a statement?"

If so, how is this any different from what Hibernate does with the ad 
hoc facility.



2) Generally does not support object identity (would be hard to do)


Ok, great.  Excellent point.

3) Allows complete hand coding of real SQL, with full support for 
nearly all RDBMS features


Fantastic!

Regards,

Abdullah

Re: iBatis and ORM's

[Abdullah Kauchali]

Larry Meadors wrote:


Man, this is a big one, and i am late already..i'll get it started.
 

Sorry.  :)  I know Friday's almost over, but I need some ammo for 
something I am preparing

for next week.


The question is not DAO vs ORM, it is ORM vs Data Mapping.
 


Got it!


ORM = mapping database objects to java objects (or c#, whatever).
 


Yeah, tables to java objects.  Cool.


Data mapping = mapping sql *statements* to java objects (c#, blah, whatever).
 

This is what I am trying to understand.  How's this any different from 
what Hibernate does?



DAO can be used with either ORM or Data Mapping.
 

Yup.  Much like what Spring does by allowing either iBatis or Hibernate 
to operate as the "data layer"?



More later...
 



Much appreciated!  Believe me!  I love you guys!  :-D

iBATIS transactional behaviour

[Konda, Sreenivasulu \(Consultant\)]

Hi 
All,
 
I would like to know 
expected behaviour of iBATIS JDBC transactions. Please see below code snippets 
and details for the same.
 
daoManager.startTransaction();
    
insert("insertToTable1", Object1);

    
insert("insertToTable2", Object2);

    
update("updateTable3", 
Object3);

    
delete("deleteFromTable1", Object1);
daoManager.commitTransaction();
 
Given above sequence 
of calls, assume that Thread1 is at update("updateTable3", Object3) call and 
Thread2 too entered into the same method where above exists.
 
Now
 
1) Will Thread2 be 
able to start another transaction before the tx1 got committed to DB, which was 
started by Thread1?
2) If Thread2 starts 
tx2, what would be the behaviour at DB level in this 
scenario?
3) If tx1 and tx2 
are allowed simultaneously, is this called as nested 
transaction?
 
BTW, transaction 
manager type is JDB as you see below XML tags from 
sqlmap_config.xml.
 
          
  
 
Please let me know 
your comments.
 
Thanks and 
regards,
Sreenivas
 
 

Re: iBatis and ORM's

[netsql]

Let me try another approach of how I answer this:

SQL is a set processing langage. You select a set, update a set where, 
etc., SQL engines are optimised for this for many decades. (See set 
theory, unions, intersections, SQL P&T, etc.)
In general, row by row processing is discuraged when working w/ SQL dbs 
and is not optimal.



So... row by row processing, or cursor processing is more ORM. ORM 
attemnts to do SQL optimizing on the Java side, by storing rows as 
objects and computing. ORM is row aware and ads complexity to Java layer.


Set processing is more SQL Mapping. Native Optimization from the SQL 
engine is leveraged. SQL mapping is not aware of rows, it's aware of a 
set of results that may be cached should somone else required identical 
result set.


hth

--
thx,
.V

Your Roomity Broadband Community 

cell: 917 825 3035 in DFW
email: netsql at roomity.com

Re: iBATIS transactional behaviour

[Larry Meadors]

In iBATIS, transacitons are managed at the thread level - you call a
shared object, but it uses thread local storage to make it happen
under the covers.

Larry


On 11/4/05, Konda, Sreenivasulu (Consultant)
<[EMAIL PROTECTED]> wrote:
>
> Hi All,
>
> I would like to know expected behaviour of iBATIS JDBC transactions. Please
> see below code snippets and details for the same.
>
> daoManager.startTransaction();
> insert("insertToTable1", Object1);
>
> insert("insertToTable2", Object2);
>
> update("updateTable3", Object3);
>
> delete("deleteFromTable1", Object1);
> daoManager.commitTransaction();
>
> Given above sequence of calls, assume that Thread1 is at
> update("updateTable3", Object3) call and Thread2 too entered into the same
> method where above exists.
>
> Now
>
> 1) Will Thread2 be able to start another transaction before the tx1 got
> committed to DB, which was started by Thread1?
> 2) If Thread2 starts tx2, what would be the behaviour at DB level in this
> scenario?
> 3) If tx1 and tx2 are allowed simultaneously, is this called as nested
> transaction?
>
> BTW, transaction manager type is JDB as you see below XML tags from
> sqlmap_config.xml.
>
> 
> 
>   
> 
>   
>
> Please let me know your comments.
>
> Thanks and regards,
> Sreenivas
>
>

Re: iBatis and ORM's

[Clinton Begin]

Try this with Hibernate:

int i = (Integer) client.queryForObject ("countUsersInGroup", "MyGroup");


  SELECT Count(1) FROM Users WHERE GroupName = #groupName#

In asking yourself why this isn't possible in Hibernate, you'll answer your first question.

To answer the third question, try this with Hibernate:

client.delete("deleteUsersInGroup", "MyGroup");





  DELETE FROM Users WHERE GroupName = #groupName#



In asking yourself why this isn't possible, you'll answer part of the third question.

The rest of the answer to the third question is this:  Generally
systems involve many more SELECT statements than INSERT, UPDATE and
DELETE combined.  Usually all of the value in a relational
database system is realized from the SELECT statements.  Nobody
makes money on INSERT, UPDATE and DELETE.  ORM solves INSERT,
UPDATE and DELETE very well (as long as you're not talking batch
updates and deletes).  But ORMs generally do very little for
SELECT, and in fact, ORMs often complicate SELECT.  Having
experienced this myself, I'll say that beyond INSERT, UPDATE by PK,
DELETE by PK and SELECT by PKORMs don't generally help much.  

What ORMs do very well though is manage the relationships between
objects and how the impact a change to one object should (or should
not) imact related objects.  ORMs also tend allow for much more
effective caching of objects (thanks to OID).  

But anyway, this is an old discussion that's become way to old. 
The real answer to your question is another question:  why are you
comparing an ORM to iBATIS? It's like comparing a Spreadsheet tool to a
Word Processor.

Cheers,
Clinton




On 11/4/05, Abdullah Kauchali <[EMAIL PROTECTED]> wrote:
Fantastic.  Some more questions in-line. Clinton Begin wrote:> ORM>> 1) Maps classes to tables, and columns to fields.Don't we do that with iBatis too?   Are we saying that mapping classes
to tables, and columns tofields is generally a bad idea?> 2) Must support Object IdentityYes, of course.  Excellent point, thanks!> 3) Generates SQLAgreed.  But tools like Hibernate allow for adhoc queries.  Could the
fact that this "escape hatch"(to allow for ad hoc or "hand written" queries) be taken as an argumentthat such tools are in factexactly like iBatis but with /more/ features?  (Did I phrase that
right?)  I guess, what I really want toask is:  what is the trade-off or compromise in the design whenHibernate users begin to use thead hoc query facilty?  (There has to be a cost!  :-)  )>
> SQL Mapping>> 1) Maps objects (not necessarily a custom type, or even the same type)> to statementsClinton, I am trying to understand this carefully.  Don't you mean "mapobjects to rows of a resultset
created from a statement?"If so, how is this any different from what Hibernate does with the adhoc facility.> 2) Generally does not support object identity (would be hard to do)Ok, great.  Excellent point.
> 3) Allows complete hand coding of real SQL, with full support for> nearly all RDBMS featuresFantastic!Regards,Abdullah

Re: iBatis and ORM's

[Kim Goings]

Clinton - This discussion is probably far too old for you since you've been around it for so long.  :)  I think it's still valid.  I've started to become quite the iBatis evangelist and when people ask why I think it is better or how it is different than Hibernate, the points you (and others) have made here are what I need to back me up.  

Like it or not, when people are deciding what to use on a project, it's not uncommon for iBatis and Hibernate to be the top two contenders.  Maybe that's a growing trend stemming from painful Hibernate experiences.  I think in many cases, people have realized they don't really need an ORM, but are fearful of pulling away because Hibernate is the "hip" way to go these days.  

They are different things and, as always, the best choice really does depend on the project.  But for the most part, I think the decision often lies in the answer to "Are you comfortable with SQL?"  or "Do you have a DBA?"  (who presumably wants more control over what your app does to the db than Hibernate allows).  

AnywayI love iBatis and would be hard-pressed to find any situation where it wasn't the best, or at least sufficient, choice.  

Kim


On Nov 4, 2005, at 4:55 PM, Clinton Begin wrote:

Try this with Hibernate:

int i = (Integer) client.queryForObject ("countUsersInGroup", "MyGroup");


  SELECT Count(1) FROM Users WHERE GroupName = #groupName#


In asking yourself why this isn't possible in Hibernate, you'll answer your first question.

To answer the third question, try this with Hibernate:

client.delete("deleteUsersInGroup", "MyGroup");


  DELETE FROM Users WHERE GroupName = #groupName#


In asking yourself why this isn't possible, you'll answer part of the third question.

The rest of the answer to the third question is this:  Generally systems involve many more SELECT statements than INSERT, UPDATE and DELETE combined.  Usually all of the value in a relational database system is realized from the SELECT statements.  Nobody makes money on INSERT, UPDATE and DELETE.  ORM solves INSERT, UPDATE and DELETE very well (as long as you're not talking batch updates and deletes).  But ORMs generally do very little for SELECT, and in fact, ORMs often complicate SELECT.  Having experienced this myself, I'll say that beyond INSERT, UPDATE by PK, DELETE by PK and SELECT by PKORMs don't generally help much.  

What ORMs do very well though is manage the relationships between objects and how the impact a change to one object should (or should not) imact related objects.  ORMs also tend allow for much more effective caching of objects (thanks to OID).  

But anyway, this is an old discussion that's become way to old.  The real answer to your question is another question:  why are you comparing an ORM to iBATIS? It's like comparing a Spreadsheet tool to a Word Processor.

Cheers,
Clinton





On 11/4/05, Abdullah Kauchali <[EMAIL PROTECTED]> wrote:
Clinton Begin wrote:

> ORM
>
> 1) Maps classes to tables, and columns to fields.

Don't we do that with iBatis too?   Are we saying that mapping classes 
to tables, and columns to
fields is generally a bad idea?

> 2) Must support Object Identity

Yes, of course.  Excellent point, thanks!

> 3) Generates SQL

Agreed.  But tools like Hibernate allow for adhoc queries.  Could the 
fact that this "escape hatch"
(to allow for ad hoc or "hand written" queries) be taken as an argument
that such tools are in fact
exactly like iBatis but with /more/ features?  (Did I phrase that 
right?)  I guess, what I really want to
ask is:  what is the trade-off or compromise in the design when
Hibernate users begin to use the
ad hoc query facilty?  (There has to be a cost!  :-)  )

>
> SQL Mapping
>
> 1) Maps objects (not necessarily a custom type, or even the same type)
> to statements

Clinton, I am trying to understand this carefully.  Don't you mean "map
objects to rows of a resultset 
created from a statement?"

If so, how is this any different from what Hibernate does with the ad
hoc facility.

> 2) Generally does not support object identity (would be hard to do)

Ok, great.  Excellent point. 

> 3) Allows complete hand coding of real SQL, with full support for
> nearly all RDBMS features

Fantastic!

Regards,

Abdullah

Re: iBatis and ORM's

[Larry Meadors]

Preamble/disclaimer: It is late on friday afternoon.

On 11/4/05, Kim Goings <[EMAIL PROTECTED]> wrote:
> Clinton - This discussion is probably far too old for you since you've
> been around it for so long.  :)  I think it's still valid.  I've

Clinton, Kim just called you OLD, I think. ;-)

> started to become quite the iBatis evangelist and when people ask why I
> think it is better or how it is different than Hibernate, the points
> you (and others) have made here are what I need to back me up.
>
> Like it or not, when people are deciding what to use on a project, it's
> not uncommon for iBatis and Hibernate to be the top two contenders.
> Maybe that's a growing trend stemming from painful Hibernate
> experiences.  I think in many cases, people have realized they don't
> really need an ORM, but are fearful of pulling away because Hibernate
> is the "hip" way to go these days.

H, does that make iBATIS a "hip"-replacement? Interesting
notion..I sense a lot of "old" humor here...

>
> They are different things and, as always, the best choice really does
> depend on the project.  But for the most part, I think the decision
> often lies in the answer to "Are you comfortable with SQL?"  or "Do you
> have a DBA?"  (who presumably wants more control over what your app
> does to the db than Hibernate allows).
>
> AnywayI love iBatis and would be hard-pressed to find any situation
> where it wasn't the best, or at least sufficient, choice.
>

I agree. 100%

Larry

Re: iBatis and ORM's

[Clinton Begin]

Sorry everyone.  I didn't mean to sound like I don't care about such comparisons.  

I think it is old for me, and I'm able to look at situation objectively
and decide whether Hibernate or iBATIS (or neither) is the best
choice.  To me, it seems obvious.

Perhaps this is a VERY long overdue FAQ that we need to add.  Anyone care to start it and begin collecting these thoughts?

I would, but apparently I'm too jaded. ;-)  

Cheers,
Clinton
On 11/4/05, Kim Goings <[EMAIL PROTECTED]> wrote:
Clinton - This discussion is probably far too old for you since you'vebeen around it for so long.  :)  I think it's still valid.  I'vestarted to become quite the iBatis evangelist and when people ask why Ithink it is better or how it is different than Hibernate, the points
you (and others) have made here are what I need to back me up.Like it or not, when people are deciding what to use on a project, it'snot uncommon for iBatis and Hibernate to be the top two contenders.Maybe that's a growing trend stemming from painful Hibernate
experiences.  I think in many cases, people have realized they don'treally need an ORM, but are fearful of pulling away because Hibernateis the "hip" way to go these days.They are different things and, as always, the best choice really does
depend on the project.  But for the most part, I think the decisionoften lies in the answer to "Are you comfortable with SQL?"  or "Do youhave a DBA?"  (who presumably wants more control over what your app
does to the db than Hibernate allows).AnywayI love iBatis and would be hard-pressed to find any situationwhere it wasn't the best, or at least sufficient, choice.KimOn Nov 4, 2005, at 4:55 PM, Clinton Begin wrote:
>>  Try this with Hibernate:>>  int i = (Integer) client.queryForObject ("countUsersInGroup",> "MyGroup");>>  > parameterClass="string">>   SELECT Count(1) FROM Users WHERE GroupName = #groupName#>  >> In asking yourself why this isn't possible in Hibernate, you'll answer
> your first question.>>  To answer the third question, try this with Hibernate:>>  client.delete("deleteUsersInGroup", "MyGroup");>>  
>   DELETE FROM Users WHERE GroupName = #groupName#>  >>  In asking yourself why this isn't possible, you'll answer part of the> third question.>>  The rest of the answer to the third question is this: Generally
> systems involve many more SELECT statements than INSERT, UPDATE and> DELETE combined. Usually all of the value in a relational database> system is realized from the SELECT statements. Nobody makes money on
> INSERT, UPDATE and DELETE. ORM solves INSERT, UPDATE and DELETE very> well (as long as you're not talking batch updates and deletes). But> ORMs generally do very little for SELECT, and in fact, ORMs often
> complicate SELECT. Having experienced this myself, I'll say that> beyond INSERT, UPDATE by PK, DELETE by PK and SELECT by PKORMs> don't generally help much.>>  What ORMs do very well though is manage the relationships between
> objects and how the impact a change to one object should (or should> not) imact related objects. ORMs also tend allow for much more> effective caching of objects (thanks to OID).>>  But anyway, this is an old discussion that's become way to old. The
> real answer to your question is another question: why are you> comparing an ORM to iBATIS? It's like comparing a Spreadsheet tool to> a Word Processor.>>  Cheers,>  Clinton>
> On 11/4/05, Abdullah Kauchali <[EMAIL PROTECTED]> wrote: Clinton Begin wrote:>>
>> > ORM>> >>> > 1) Maps classes to tables, and columns to fields. Don't we do that with iBatis too? Are we saying that mapping classes>> to tables, and columns to
>> fields is generally a bad idea? > 2) Must support Object Identity Yes, of course.Excellent point, thanks! > 3) Generates SQL>>
>> Agreed.But tools like Hibernate allow for adhoc queries.Could the>> fact that this "escape hatch">> (to allow for ad hoc or "hand written" queries) be taken as an>> argument
>> that such tools are in fact>> exactly like iBatis but with /more/ features?(Did I phrase that>> right?)I guess, what I really want to>> ask is:what is the trade-off or compromise in the design when
>> Hibernate users begin to use the>> ad hoc query facilty?(There has to be a cost!:-)) >>>  > SQL Mapping>> >>> > 1) Maps objects (not necessarily a custom type, or even the same
>> type)>> > to statements Clinton, I am trying to understand this carefully.Don't you mean>> "map>> objects to rows of a resultset>> created from a statement?"
 If so, how is this any different from what Hibernate does with the ad>> hoc facility. > 2) Generally does not support object identity (would be hard to do)
 Ok, great.Excellent point. > 3) Allows complete hand coding of real SQL, with full support for>> > nearly all RDBMS features Fantastic!
 Regards, Abdullah>>

Re: iBatis and ORM's

[Clinton Begin]

>> Clinton, Kim just called you OLD, I think. ;-)

Yeah, but in dog years, I'm only 4.

ClintonOn 11/4/05, Larry Meadors <[EMAIL PROTECTED]
> wrote:
Preamble/disclaimer: It is late on friday afternoon.On 11/4/05, Kim Goings <[EMAIL PROTECTED]
> wrote:> Clinton - This discussion is probably far too old for you since you've
> been around it for so long.  :)  I think it's still valid.  I'veClinton, Kim just called you OLD, I think. ;-)> started to become quite the iBatis evangelist and when people ask why I> think it is better or how it is different than Hibernate, the points
> you (and others) have made here are what I need to back me up.>> Like it or not, when people are deciding what to use on a project, it's> not uncommon for iBatis and Hibernate to be the top two contenders.
> Maybe that's a growing trend stemming from painful Hibernate> experiences.  I think in many cases, people have realized they don't> really need an ORM, but are fearful of pulling away because Hibernate
> is the "hip" way to go these days.H, does that make iBATIS a "hip"-replacement? Interestingnotion..I sense a lot of "old" humor here...>> They are different things and, as always, the best choice really does
> depend on the project.  But for the most part, I think the decision> often lies in the answer to "Are you comfortable with SQL?"  or "Do you> have a DBA?"  (who presumably wants more control over what your app
> does to the db than Hibernate allows).>> AnywayI love iBatis and would be hard-pressed to find any situation> where it wasn't the best, or at least sufficient, choice.>I agree. 100%
Larry

Re: iBatis and ORM's

[Kim Goings]

I will try.  I've only been able to convert 2 people so far and would love to reach more.  :) 

Kim

On Nov 4, 2005, at 5:49 PM, Clinton Begin wrote:

Sorry everyone.  I didn't mean to sound like I don't care about such comparisons. 

I think it is old for me, and I'm able to look at situation objectively and decide whether Hibernate or iBATIS (or neither) is the best choice.  To me, it seems obvious.

Perhaps this is a VERY long overdue FAQ that we need to add.  Anyone care to start it and begin collecting these thoughts?

I would, but apparently I'm too jaded. ;-)  

Cheers,
Clinton

On 11/4/05, Kim Goings <[EMAIL PROTECTED]> wrote:
been around it for so long.  :)  I think it's still valid.  I've
started to become quite the iBatis evangelist and when people ask why I
think it is better or how it is different than Hibernate, the points 
you (and others) have made here are what I need to back me up.

Like it or not, when people are deciding what to use on a project, it's
not uncommon for iBatis and Hibernate to be the top two contenders.
Maybe that's a growing trend stemming from painful Hibernate
experiences.  I think in many cases, people have realized they don't
really need an ORM, but are fearful of pulling away because Hibernate
is the "hip" way to go these days.

They are different things and, as always, the best choice really does 
depend on the project.  But for the most part, I think the decision
often lies in the answer to "Are you comfortable with SQL?"  or "Do you
have a DBA?"  (who presumably wants more control over what your app 
does to the db than Hibernate allows).

AnywayI love iBatis and would be hard-pressed to find any situation
where it wasn't the best, or at least sufficient, choice.

Kim


On Nov 4, 2005, at 4:55 PM, Clinton Begin wrote: 

>
>  Try this with Hibernate:
>
>  int i = (Integer) client.queryForObject ("countUsersInGroup",
> "MyGroup");
>
>  
> parameterClass="string">
>   SELECT Count(1) FROM Users WHERE GroupName = #groupName#
>  
>
> In asking yourself why this isn't possible in Hibernate, you'll answer 
> your first question.
>
>  To answer the third question, try this with Hibernate:
>
>  client.delete("deleteUsersInGroup", "MyGroup");
>
>  
>   DELETE FROM Users WHERE GroupName = #groupName#
>  
>
>  In asking yourself why this isn't possible, you'll answer part of the
> third question.
>
>  The rest of the answer to the third question is this: Generally 
> systems involve many more SELECT statements than INSERT, UPDATE and
> DELETE combined. Usually all of the value in a relational database
> system is realized from the SELECT statements. Nobody makes money on
> INSERT, UPDATE and DELETE. ORM solves INSERT, UPDATE and DELETE very
> well (as long as you're not talking batch updates and deletes). But
> ORMs generally do very little for SELECT, and in fact, ORMs often 
> complicate SELECT. Having experienced this myself, I'll say that
> beyond INSERT, UPDATE by PK, DELETE by PK and SELECT by PKORMs
> don't generally help much.
>
>  What ORMs do very well though is manage the relationships between 
> objects and how the impact a change to one object should (or should
> not) imact related objects. ORMs also tend allow for much more
> effective caching of objects (thanks to OID).
>
>  But anyway, this is an old discussion that's become way to old. The 
> real answer to your question is another question: why are you
> comparing an ORM to iBATIS? It's like comparing a Spreadsheet tool to
> a Word Processor.
>
>  Cheers,
>  Clinton
> 
>
>
>
>
> On 11/4/05, Abdullah Kauchali <[EMAIL PROTECTED]> wrote:
>>
>> Clinton Begin wrote:
>> 
>> > ORM
>> >
>> > 1) Maps classes to tables, and columns to fields.
>>
>> Don't we do that with iBatis too? Are we saying that mapping classes
>> to tables, and columns to 
>> fields is generally a bad idea?
>>
>> > 2) Must support Object Identity
>>
>> Yes, of course.Excellent point, thanks!
>>
>> > 3) Generates SQL
>> 
>> Agreed.But tools like Hibernate allow for adhoc queries.Could the
>> fact that this "escape hatch"
>> (to allow for ad hoc or "hand written" queries) be taken as an
>> argument 
>> that such tools are in fact
>> exactly like iBatis but with /more/ features?(Did I phrase that
>> right?)I guess, what I really want to
>> ask is:what is the trade-off or compromise in the design when 
>> Hibernate users begin to use the
>> ad hoc query facilty?(There has to be a cost!:-))
>>
>> >
>>  > SQL Mapping
>> >
>> > 1) Maps objects (not necessarily a custom type, or even the same 
>> type)
>> > to statements
>>
>> Clinton, I am trying to understand this carefully.Don't you mean
>> "map
>> objects to rows of a resultset
>> created from a statement?" 
>>
>> If so, how is this any different from what Hibernate does with the ad
>> hoc facility.
>>
>> > 2) Generally does not support object identity (would be hard to do)
>>
>> Ok, great.Excellent point.
>>
>> > 3) Allows complete hand coding of real SQL, with full support for
>> > nearly

Re:iBATIS transactional behaviour

[ooper]

I suspect it depends on the rdbms being used and how it is configured; row level locks, page level locks, table level locks. I'm notsure this is affected by iBATIS.Scenario 1: Thread2 will be able to start a tx, but may have to wait for Thread1 to commit/rollback before it can commit/rollback. This depends on locking mechanism on the table(s). If the entire table is locked, thread2 will be waiting. If a row is locked, thread2may be able to run simultaneously, granted the same row is not being updated.Scenario 2: Depends on locking mechanism of involved tables, and whether the affected rows in thread1 and thread2 are the same.Scenario 3: No, they are separate and distinct transactions.I'd suggest reading up on how transactions and locking are handled by your rdbms.Brian BarnettBroadband interface (RIA) + mail box saftey = iBatis_for_Java_Users_List.roomity.com*Your* clubs, no sign up to read, ad supported; try broadband internet. ~~1131151519724~~

Re: iBatis and ORM's

[Clinton Begin]

But if those two people convert two people each.exponential growth!On 11/4/05, Kim Goings <
[EMAIL PROTECTED]> wrote:I will try.  I've only been able to convert 2 people so far and would
love to reach more.  :)KimOn Nov 4, 2005, at 5:49 PM, Clinton Begin wrote:>>  Sorry everyone. I didn't mean to sound like I don't care about such> comparisons.>>  I think it is old for me, and I'm able to look at situation
> objectively and decide whether Hibernate or iBATIS (or neither) is the> best choice. To me, it seems obvious.>>  Perhaps this is a VERY long overdue FAQ that we need to add. Anyone> care to start it and begin collecting these thoughts?
>>  I would, but apparently I'm too jaded. ;-)>>  Cheers,>  Clinton>> On 11/4/05, Kim Goings <[EMAIL PROTECTED]
> wrote:>> been around it for so long.:)I think it's still valid.I've>> started to become quite the iBatis evangelist and when people ask why>> I>> think it is better or how it is different than Hibernate, the points
>> you (and others) have made here are what I need to back me up. Like it or not, when people are deciding what to use on a project,>> it's>> not uncommon for iBatis and Hibernate to be the top two contenders.
>> Maybe that's a growing trend stemming from painful Hibernate>> experiences.I think in many cases, people have realized they don't>> really need an ORM, but are fearful of pulling away because Hibernate
>> is the "hip" way to go these days. They are different things and, as always, the best choice really does>> depend on the project.But for the most part, I think the decision
>> often lies in the answer to "Are you comfortable with SQL?"or "Do>> you>> have a DBA?"(who presumably wants more control over what your app>> does to the db than Hibernate allows).
 AnywayI love iBatis and would be hard-pressed to find any>> situation>> where it wasn't the best, or at least sufficient, choice. Kim>>
 On Nov 4, 2005, at 4:55 PM, Clinton Begin wrote: >>> >Try this with Hibernate:>> >>> >int i = (Integer) client.queryForObject ("countUsersInGroup",
>> > "MyGroup");>> >>> >>> > parameterClass="string">>> > SELECT Count(1) FROM Users WHERE GroupName = #groupName#
>> >>> >>> > In asking yourself why this isn't possible in Hibernate, you'll>> answer>> > your first question.>> >>> >To answer the third question, try this with Hibernate:
>> >>> >client.delete("deleteUsersInGroup", "MyGroup");>> >>> >
>> > DELETE FROM Users WHERE GroupName = #groupName#>> >>> >>> >In asking yourself why this isn't possible, you'll answer part of>> the>> > third question.
>> >>> >The rest of the answer to the third question is this: Generally>> > systems involve many more SELECT statements than INSERT, UPDATE and>> > DELETE combined. Usually all of the value in a relational database
>> > system is realized from the SELECT statements. Nobody makes money on>> > INSERT, UPDATE and DELETE. ORM solves INSERT, UPDATE and DELETE very>> > well (as long as you're not talking batch updates and deletes). But
>> > ORMs generally do very little for SELECT, and in fact, ORMs often>> > complicate SELECT. Having experienced this myself, I'll say that>> > beyond INSERT, UPDATE by PK, DELETE by PK and SELECT by PKORMs
>> > don't generally help much.>> >>> >What ORMs do very well though is manage the relationships between>> > objects and how the impact a change to one object should (or should
>> > not) imact related objects. ORMs also tend allow for much more>> > effective caching of objects (thanks to OID).>> >>> >But anyway, this is an old discussion that's become way to old. The
>> > real answer to your question is another question: why are you>> > comparing an ORM to iBATIS? It's like comparing a Spreadsheet tool>> to>> > a Word Processor.>> >
>> >Cheers,>> >Clinton>> >>> >>> >>> >>> >>> > On 11/4/05, Abdullah Kauchali <
[EMAIL PROTECTED]> wrote:>>  >> Clinton Begin wrote:>>  >> > ORM>> >> >>> >> > 1) Maps classes to tables, and columns to fields.
>>  >> Don't we do that with iBatis too? Are we saying that mapping>> classes>> >> to tables, and columns to>> >> fields is generally a bad idea?
>>  >> > 2) Must support Object Identity>>  >> Yes, of course.Excellent point, thanks!>>  >> > 3) Generates SQL
>>  >> Agreed.But tools like Hibernate allow for adhoc queries.Could the>> >> fact that this "escape hatch">> >> (to allow for ad hoc or "hand written" queries) be taken as an
>> >> argument>> >> that such tools are in fact>> >> exactly like iBatis but with /more/ features?(Did I phrase that>> >> right?)I guess, what I really want to
>> >> ask is:what is the trade-off or compromise in the design when>> >> Hibernate users begin to use the>> >> ad hoc query facilty?(There has to be a cost!:-))>> >>
>> >> >>> >>> SQL Mapping>> >> >>> >> > 1) Maps objects (not necessarily a custom type, or even the same>> >> type)>> >> > to statements
>>  >> Clinton, I am trying to understand this carefully.Don't you mean>> >> "map>> >> objects to r

parameterMap for Oracle's "select * from Table(f(x))"

[Balayn, Anna]

Title: parameterMap for Oracle's "select * from Table(f(x))"







Can someone help?


I am having a problem executing the following statement with queryWithRowHandler():


rmap" parameterMap="pmap">
    select * from TABLE (func(?))



This is working fine:


rmap" parameterMap="pmap">
    select * from TABLE (func(12345))



But once I specify a parameter map (or a parameter class, I tried both ways), I get an error like this one: "--- The error occurred while applying a parameter map".  

The parameter map itself is fine, it is for some reason not mapping with this statement.


Thanks
Anna B







This e-mail message and any attachments contain confidentialinformation from Medco. If you are not the intended recipient, you arehereby notified that disclosure, printing, copying, distribution, orthe taking of any action in reliance on the contents of this electronicinformation is strictly prohibited. If you have received this e-mailmessage in error, please immediately notify the sender by reply messageand then delete the electronic message and any attachments.

Re: iBatis and ORM's

[Abdullah Kauchali]

netsql wrote:


Let me try another approach of how I answer this:



Thanks, I appreciate it greatly!  :)



SQL is a set processing langage. You select a set, update a set where, 
etc., SQL engines are optimised for this for many decades. (See set 
theory, unions, intersections, SQL P&T, etc.)
In general, row by row processing is discuraged when working w/ SQL 
dbs and is not optimal.



Ok, so it is always going to be less efficient to iterate through a 
collection of instantiated objects
(objects that relate to rows in a table) in the application "process 
tier" (or outside the RDBMS process)
/than/ it would to do a SELECT COUNT(*) FROM TABLE, get the resulting 
int and run with it!


Got it.

So... row by row processing, or cursor processing is more ORM. ORM 
attemnts to do SQL optimizing on the Java side, by storing rows as 
objects and computing. ORM is row aware and ads complexity to Java layer.


Got it.

Set processing is more SQL Mapping. Native Optimization from the SQL 
engine is leveraged. SQL mapping is not aware of rows, it's aware of a 
set of results that may be cached should somone else required 
identical result set. 



Now this is where the "heart" of my question is!  :)

We all know that iBatis returns Java objects that are mapped to 
/resultsets/ of a statement.  That is
how we all use it.  We have a User table and we have a mapped statement 
that tells the iBatis
library to "take the resultset from that query and create Java objects 
from it" - based on the class

(name) we give it - in this case a User Class.

Now, isn't that the central premis of an ORM - to give the developer the 
ability to see his/her tables and
rows as Classes and Properties?  We are not simply refering to "typed 
datasets" here (like we have in
.NET). JDBC Resultsets, in a way, are already "typed" - so, that's no 
even what iBatis returns.  As a matter
of fact, iBatis "best practices"  encourage the concept of OO 
containment too (where an object can contain a
list of other objects) - representing a 1-to-many relationship.   (Typed 
dataset don't have this level of
"sophistication" - a concept very much steeped in the semantics of OO.  
Typed datasets would simply carry
foreign key links, very much like the tables they represent on a 
RDBMS.)  iBatis is much more closer to the

OO side than it is to the idea of "SETS".

The point I am making is that, it looks like iBatis has /intentions/ of 
answering the fundamental questions
that all ORM's have ambitions of solving - the primary one being the 
ability to give the programmer a
/natural/ (cough!) feel for their objects.   (Gee, I could puke every 
time the ORM folks say that.)  To use
OO concepts like inheritance, polymorphism to construct their problem 
domain.   (I am not saying this
is possible with iBatis, I am saying that iBatis gives that impression 
when we start do the mapping of

resultsets from mapped statements to Java classes.)

Another way of seeing this apparent iBatis "identity crisis" -  
(Clinton, I mean no offense here, and this is
not my primary objective for this particular discussion :) ) - is the 
glaring lack of support for returning the
concept of RESULTSETS or /disconnected/ resultsets like CachedRowSet or 
WebRowSet.  (Are you

smiling, Clinton?)  :-)

IMO, we need them badly!  If we are going to compare iBatis with a 
spreadsheet and ORM's with
Wordprocessors  (an analogy I absolutely accept!), then where is my 
"spreadsheet" from iBatis.  (The
RowHandler stuff is not an answer btw because I have to create my 
"dataset" myself.)


Kind regards,

Abdullah