Can you do analytic SQL with ORM?you do selections from vitrual tables?select&nbsp;&nbsp;xx,&nbsp;&nbsp;yyfromselect&nbsp;&nbsp;zz,&nbsp;&nbsp;aaCan you do inserts using selects?insert into xxx( col1, col2, col3)) values (select xx, yy, zz from aa where aaa)?Can you do decodes?Didn't think so.Of course, the problem is that you can't do these with general SQL either. You can only do all these with some implementations of SQL on some database engines. Your mention of 'decodes' is illustrative, as this is an Oracle-only function.And, this has nothing to do with the use or non-use of ORM. ORM is simply a more elegant and transparent interface to databases than JDBC, and irrelevant to what you can or can't do. You don't do, for example, analytic calculations with JDBC - you do it with the SQL language. In the same way, you don't do such things with ORM, but there is nothing stopping you from doing analytic calculations in a language that has an ORM interface. Anyway, the answer to your question is "Yes".For example, in JDO 2.0, you can pass any SQL to the underlying database.
It has everything to do with ORM...
ORM encourages you to NOT use vendor specific SQL, but instead to use some ORM package specific (non portable) 'query' API.
If you are using vendor specific SQL, you are not using the ORM's query API.
At that point, there is no point in using ORM at all.
JDBC is so stupidly simple.
Connection c = getConnection();
Statement s = c.createStatement();
ResultSet rs = s.executeQuery("select xxx from yyy");
// put data where ever you want it
that is it. I can teach it to any idiot in minutes.
The ORM croud have done a master 'con' job in convincing people that JDBC is complicated and ORM is much easier.
ORM adds a HUGE layer of additional complexity, and causes a significant performance hit in most situations. Take updates for example, when you update through ORM, it has to update all caches in the cluster, so instead of one trip to the database, you have 5 network trips (or how ever many nodes you have in your cluster). The apps I work on do a lot of updates. ORM made it dog slow.
Things get even worse when external apps update the database outside or the ORM app. Why do Java developers always think their app will be the center of the universe???
On top of that, ORM just seems to loose the order up updates to particular objects. You just get updates to the database in whatever order the ORM sees fit. To hell with logging and auditing I guess.
In addition, ORMs often do stupid things like copy the entire dataset into bean objects. This is stupid because some drivers already copy the entire dataset into memory (i.e. the MySQL driver). So ORM is doing double work and is slower than strait JDBC.
I have not even started on all the problems with mapping that you'll encounter with ORM. JDBC simply avoids all of these problems.
ORM is slower, more complicated, more buggy, and in some cases not even functionally correct (see issue with mysql above). ORM is *not* more elegant when you have to jump through a million programming hoops just to do what is simple in JDBC.
The Java ORM croud should be congratulated at the masterful con job they have done.