The JDBC 4.0 API Specification (JSR-221) has an early draft available for review.

The overview of changes includes the following elements:

• Automatic loading of java.sql.Driver through the Service Provider mechanism
• Ease of Development through Annotations and a generic DataSet
• ROWID data type
• National Character Set support
• Enhanced support for BLOB and CLOB
• SQL/XML and XML support
• Wrapper Pattern allows the use of non-standard JDBC methods provided by vendor implementations
• SQLException enhancements
• Connection Management
• Many other API changes

Congratulations for the JDBC 4.0 Expert Group :-) As the former specification lead, it is very gratifying to see all the hard work deliver a draft specification. Great stuff Lance!

"Ease of Development through Annotations and a generic DataSet"
Is it going to become O/R mapping framework ? I like this way to execute SQL queries and I am afraid it will kill EJB :), but I think it useless for connectivity API, it can be a separate framework and this framework can work with any driver.

"JDBC compliance requires full support for the JDBC API and full support for SQL 92 Entry Level."
It is outdated, is not it ? I think SQL "upgrade" is more usefull than any new/experimental feature.

"JDBC compliance requires full support for the JDBC API and full support for SQL 92 Entry Level."It is outdated, is not it ? I think SQL "upgrade" is more usefull than any new/experimental feature.

I agree. My opinion is that too much of the JDBC API has been about providing tests for compliance with different aspects if SQL standards, and there has not been enough emphasis on requiring compliance with SQL standards. Compliance with a 13-year old standard does indeed seem outdated.

who can privide the url to download the spec? thank you

If you go to the JSR page, there's a "Download Early Draft" link. That's your URL.

Good.

Maybe with this we can finally do away with all of this convoluted ORM stuff.

I developed and used this kind of framework myself http://voruta.sf.net , it is very similar stuff implemented using javadoc comments, but it is very far from ideal framework to access data (there are a few problems). This stuff needs more research and probably new data access language, it is very srange to see this experiment in JDBC specification.

How do you suppose a Relational Database API will solve the Object-Relational Impedence mismatch?

I suppose with a hammer, chisel, and stones we could do without all those convoluted computer thingys as well.

How do you suppose a Relational Database API will solve the Object-Relational Impedence mismatch?I suppose with a hammer, chisel, and stones we could do without all those convoluted computer thingys as well.

Give me a break.

For years JDBC was used for the vast majority of Java apps that talk to a database.

Recently, the 'enlightened' Java propeller heads seem to think that JDBC is like bear skins and knives.

That is total BS.

Can you do analytic SQL with ORM?

http://www.akadia.com/services/ora_analytic_functions.html

Can you do selections from vitrual tables?

select
  xx,
  yy
from
select
  zz,
  aa

Can 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.

I just listened to the multimedia presentation at hibernate.org. These people who wrote this are clueless.

One of the main guys did not even know what selecting from a virtual table was...he thought it was a sub select in a where clause. Does not give me much confidence in ORM.

You can have your 'mismatch' all you want. For real work, use JDBC.

Mike

It's not a problem to do native sql querys with hibernate or jdo... this just shows how clueless you are when it comes to hibernate.
For your real work jdbc might be good enough or perhaps you just don't know what your missing.. a lot of people are already using hibernate and other ORM solutions to do real work.

Mike,

Stored Procedure would be good solution
for all this DB-specifics, hints, analytics,
bulk loads, inline views, etc. You can
even get cursor from procedure

AV

Nothing prevents you from using SQL through JDBC for things that benifits from it. So settle down.

Can you do analytic SQL with ORM?

you do selections from vitrual tables?

select  xx,  yyfromselect  zz,  aa

Can 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.

Can you do analytic SQL with ORM?you do selections from vitrual tables?select  xx,  yyfromselect  zz,  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");
while(rs.next())
{
  // put data where ever you want it
}
if(rs!=null) rs.close
if(s!=null) s.close();

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.

So far I have found that ORM works where requirements are simple, Database is modeled keeping in view that it has to be mapped to business objects and object graph is not very deep. Interestingly, this is exactly what is not going to happen in real-big projects. Homeworks are a different beast altogether!

So far I have found that ORM works where requirements are simple, Database is modeled keeping in view that it has to be mapped to business objects and object graph is not very deep. Interestingly, this is exactly what is not going to happen in real-big projects. Homeworks are a different beast altogether!

I would say the opposite - ORM works best where requirements are complex, as it can help to hide and automate the overhead of interfacing the business model with the database. This means that a complex business model can be developed without having the constant requirement to consider every aspect of how this model is to be represented in the database.

I would suggest that the very widespread use of ORM by major corporations with complex data models backs me up.

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.

You are confusing the query language of ORM (one very small aspect) with all the other aspects - transparent persistence, persistence by reachability etc - the things that make life easier for the developer. All modern ORMs allow vendor specific SQL.

JDBC is so stupidly simple.Connection c = getConnection();Statement s = c.createStatement();ResultSet rs = s.executeQuery("select xxx from yyy");while(rs.next()){  // put data where ever you want it}if(rs!=null) rs.closeif(s!=null) s.close();that is it.

I would not call that simple!

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.

No, years of using JDBC do that!

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).

No, this is just not true. ORM dramatically removes and hides complexity. There is no reason for significant performance hits, and any decent ORM has the ability to disable or enable cluster caches as required for performance.

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.

I have rarely seen so many 'straw man' arguments in a single paragraph!

- ORMs can interact perfectly well with existing relational models in databases that can be use by other applications.

- ORMs DO NOT 'just seem to lose updates' (if this were the case they would not be used by major financial organisations!).

- ORMs do not 'just update in whatever order' - the order is very precisely defined by the type of query, the presence of otherwise of JDBC batching, and transactions.

- ORMs DO NOT copy the entire dataset into bean objects. Both the number of rows that are retrieved in a batch can be defined, and which columns are required to be retrieved by default into beans for a particular query can be defined (with the others being optionally lazy-loaded if required).

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.

Of course it doesn't. If a driver loads the entire dataset into memory, this is as much of a problem for JDBC as it is for ORM.

The Java ORM croud should be congratulated at the masterful con job they have done.

ORM is there because it works, and works well. It is used by some very high performance applications that can't tolerate failure, such as EBay. I think it is unlikely to be the case that EBay has been 'conned'! On the contrary, it is one of the most profitable companies on the internet. Clear evidence that ORM can be very fast and very reliable.

To clairify, I meant to say that ORM loses the ORDER of updates.

We do extensive auditing in our DB, and losing the order that the objects were updated in a transaction is unacceptable.

Again with JDBC, this was not a problem. Using ORM *created* problems that we have to work our way around.

On top of that, we used a 'metadata' style database where there are many types of 'entities' stored within one table. So to add an attribute to one of the entities, you simply add a row of data. ORM does not map well to this kind of a system of data that is dynamically defined.

Again with JDBC, this was not a problem. Using ORM *created* problems that we have to work our way around.

I could go on and on, but I'm going out so I don't have time for this. Lets just say that our developers were *begging* to go back to JDBC/Vendor specific SQL after developing 2 ORM apps.

Mike

To clairify, I meant to say that ORM loses the ORDER of updates.We do extensive auditing in our DB, and losing the order that the objects were updated in a transaction is unacceptable.

I would really suggest that this is not a general ORM problem. If you want to get individual updates in a specific order this is very simple to arrange (at least in the ORM products I have used). Some ORMs by default will attempt to batch and re-organise updates for efficiency and to allow them to tune the generated SQL, but these features can be turned off. (just like the clustered cacheing mentioned previously). I rely a lot on the logging and auditing features of the ORM I use.

Again with JDBC, this was not a problem. Using ORM *created* problems that we have to work our way around.On top of that, we used a 'metadata' style database where there are many types of 'entities' stored within one table. So to add an attribute to one of the entities, you simply add a row of data. ORM does not map well to this kind of a system of data that is dynamically defined.Again with JDBC, this was not a problem. Using ORM *created* problems that we have to work our way around.I could go on and on, but I'm going out so I don't have time for this. Lets just say that our developers were *begging* to go back to JDBC/Vendor specific SQL after developing 2 ORM apps.Mike

I can certainly see that there are some situations where trying to map objects to a particular table structure and use is inappropriate. However, I still don't really see why this is a either/or JDBC/ORM situation. If you want to use direct SQL, all modern ORMs will allow that. If you want to define dynamic queries and fetch back various mixtures of columns as a result, they will allow that too (for example, JDO 'projections'). In sort, any modern ORM (Hibernate 3.0, JDO 2.0 etc) will allow a very 'non-ORM' way of working when appropriate, but with the option of still using ORM features at some point - you don't need to force everything into mapped objects.

I was taking issue with your previous post so strongly because I felt you were making general (and I believed, false) critical statements about ORM (regarding performance, cacheing, object loading).

To clairify, I meant to say that ORM loses the ORDER of updates.We do extensive auditing in our DB, and losing the order that the objects were updated in a transaction is unacceptable.Again with JDBC, this was not a problem. Using ORM *created* problems that we have to work our way around.On top of that, we used a 'metadata' style database where there are many types of 'entities' stored within one table. So to add an attribute to one of the entities, you simply add a row of data. ORM does not map well to this kind of a system of data that is dynamically defined.Again with JDBC, this was not a problem. Using ORM *created* problems that we have to work our way around.I could go on and on, but I'm going out so I don't have time for this. Lets just say that our developers were *begging* to go back to JDBC/Vendor specific SQL after developing 2 ORM apps.Mike

Fine. It sounds like your requirements are so specific that a ORM tool would be an ill fit for you. However, can you accept that those of us who choose to use ORMs have an equal ability to understand our problems and are just as certain that ORMs are appropriate?

Fine. It sounds like your requirements are so specific that a ORM tool would be an ill fit for you. However, can you accept that those of us who choose to use ORMs have an equal ability to understand our problems and are just as certain that ORMs are appropriate?

I'll buy that.

I'm just sick of the ORM croud making false claims about how 'hard' JDBC is and how ORM just does everything magically with the snap of the fingers.

For our apps, ORM caused much greef and performance problems. I have no doubt that for other types of apps, ORM might be fine.

Thing that gets me mad is at hibernate.org they have some audio presentations that basically say JDBC==BAD, ORM==GOOD.

That is BS. That is .NET evangelest level propaganda.

For some types of apps, ORM is a bad fit. The best tool for the job is what should be used. In our case, it was JDBC/Vendor specific SQL and stored procedures.

I work around a bunch of DBA's and they all laugh at this ORM stuff. They spend their time reading stuff like asktom:

http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:883929178230

Anyway, if you like ORM, use it. But don't tell the rest of the world that it is the 'silver bullet' that will solve all of your problems.

I'll buy that.I'm just sick of the ORM croud making false claims about how 'hard' JDBC is and how ORM just does everything magically with the snap of the fingers.For our apps, ORM caused much greef and performance problems.
....
Thing that gets me mad is at hibernate.org they have some audio presentations that basically say JDBC==BAD, ORM==GOOD. That is BS. That is .NET evangelest level propaganda.

I try to be diplomatic in my response when Hibernate is mentioned! Perhaps the best thing to say is that Hibernate certainly does not represent all aspects of ORM (or other ways that objects can be persisted) in Java. Hibernate is not the 'ORM crowd'. Although Hibernate is undoubtedly a high-quality product, I don't use it and I disagree with some of their attitudes to persistence.

I would not say that JDBC is hard. My personal view is that the nature and number of API calls required in JDBC is tedious and it distracts from the logic of an application. Whatever is stored in the database, I would rather concentrate on manipulating that information in terms of Java objects. When I do processing of information, I don't like to have mechanisms of storage and retrieval visible in the code that does the processing. I have concerns about code and logic portability - I often develop and test on one database, and deploy on another. A good ORM (I use a JDO product) allows me to work like this.

I know from experience and detailed research that an well-configured ORM can provide very high performance - even equal to that of stored procedures, and I'd be interested to know what the ORM you had problems with was, if you are in a position to say this.

I work around a bunch of DBA's and they all laugh at this ORM stuff.

All I can say, is .. well, they would, wouldn't they? Their job and experience is based around the database engine and SQL. This does remind me of the attitude of C/C++ developers to Java - the idea that a language that abstracts from their platform could be fast and useful was laughed at for years. I consider the attitude of DBAs to portable ORM to be similar.

Anyway, if you like ORM, use it. But don't tell the rest of the world that it is the 'silver bullet' that will solve all of your problems.

And in return, I would say don't post that ORM in general is slow, has cache problems, has update/logging/auditing problems etc. This may be your experience with one particular ORM, for your situation, but it is not my experience with mine, and there are a large number of examples of ORM implementations that don't suffer from these issues.

...would have us coding our OO code in PL/SQL.

At least 80% of the DB access is find with ORM tools (generated SQL), it's when the complicated reports with multiple joins and calculations come in that I's start hard coding SQL statements and using stored procedures.

Best tool for the job, always a safe bet.

Best tool for the job, always a safe bet.

No, that statement is generally one of the most misused claims in IT history.

A tool (such as ORM) may well be the "best tool for the job", yet it may be overall inefficient, as it requires additional learning, configuration, configuration management, infrastrcuture impact (network, cache updates), language fragmentation (yet another query language), side effects (unwanted and unanticipated data base trips and updates), efficiency losses (suboptimal queries) and so on.

Simplest tool for the job. Always a safe bet.

Best tool for the job, always a safe bet.

No, that statement is generally one of the most misused claims in IT history. A tool (such as ORM) may well be the "best tool for the job", yet it may be overall inefficient, as it requires additional learning, configuration, configuration management, infrastrcuture impact (network, cache updates), language fragmentation (yet another query language), side effects (unwanted and unanticipated data base trips and updates), efficiency losses (suboptimal queries) and so on.

Yet again we get a list of how ORM may go wrong in certain cases. Any approach can go wrong like this, including JDBC:

- additional learning: you have to know the specific SQL for the database to use it efficiently, so there is learning for each vendor.

- configuration, and configuration management: you have do deal with things like pooled connections, and handle drivers and connections in code.

- language fragmentation: yet another SQL dialect for each platform.

- side effects (unwanted and unanticipated data base trips and updates), efficiency losses (suboptimal queries): This is just bad coding, and is equally possible with poor use of JDBC and the embedded SQL.

Simplest tool for the job. Always a safe bet.

Absolutely. Pick the tool that automates things, hides complexity, cleanly separates concerns, yet allows native (optimised) SQL where appropriate. That is ORM.

As I said earlier, this debate reminds me very strongly of the type of arguments C/C++ coders used against Java - they often declared that a language that automatically managed memory and other resources would always be slow and inefficient. Java has proved them wrong. Now we get the same type of argument about object persistence - ORM must always be slower and generate inefficient sloppy SQL. Well, ORM is maturing. Although it is easy to use ORM badly and get poor results, it is also possible to use ORM to get a huge increase in development speed, code simplicity, portability and maintainability.

Object modeling and Database modeling have entirely different approaches. ORM came into picture to
1. Bridge these two different worlds.
2. Avoid writing/learning SQL which in some way tie you to the database.
Now consider these -
1. If you have a go-by-the-book database model, you are done.
Objects are not always mappable to tables. You will end up doing reverse engineering.
2. More often that not, your data-analysts would ask for bulk changes in data, and the timeline would not permit you to write a code to access the ORM api. You would rather hit the database directly. Caching strategy fails there.
3. Users don't care what best-practices you have followed. They want the application to be fast. In a relational database, where millions of records are searchable, you cannot live without tuning queries. That would bring SQL back in the game.

Having said that, ORM helps and in 8 out of 10 cases it would make the work simpler for a developer. Rest 2 would the critical performance cases where it would not.
It cannot be designated as an alternative to SQL.
We want the best of both worlds!

Yet again we get a list of how ORM may go wrong in certain cases. Any approach can go wrong like this, including JDBC:- additional learning: you have to know the specific SQL for the database to use it efficiently, so there is learning for each vendor ...

Are you going to provoke new silly discussion about good objects and bad records ?

Yet again we get a list of how ORM may go wrong in certain cases. Any approach can go wrong like this, including JDBC:- additional learning: you have to know the specific SQL for the database to use it efficiently, so there is learning for each vendor ...

Are you going to provoke new silly discussion about good objects and bad records ?

A discussion which said that would indeed be silly. After all, ORM would be rather pointless with out the records to map to, wouldn't it?

I am not trying to provoke anything; my intention is to clear up what I believe to be misunderstandings about the capabilities and nature of ORM products.

The point I was making was that if there was to be discussion of 'query language fragmentation', a more appropriate topic would be SQL itself rather than (as implied) the different query languages of different ORMs.

However, a discussion about the portability or otherwise of SQL (which is my impression from the quoted section), would simply be repeating material that has been covered in depth in previous threads.

I think SQL and JDBC API portability is not a good argument to advokate ORM, it is possible to find "portability problem" in ORM or in XRM if you want to see negative aspects. I will be happy if this discussion become more constructive and help JDBC to solve portability problems, it is the main JDBC goal. ORM goal is model transformation and this has nothing to do with portability.

I think SQL and JDBC API portability is not a good argument to advokate ORM, it is possible to find "portability problem" in ORM or in XRM if you want to see negative aspects.

No. We have discussed this before in great detail. You don't see portability problems in ORM. If someone has a JDO 2.0 implementation, then you will get all JDO 2.0 features, including all aspects of the JDO 2.0 query language on all database platforms that the implementation supports, no matter how poor the SQL implementation on those platforms.

If you wish to go over these arguments again, I can look up the details of previous threads where these matters were discussed.

I will be happy if this discussion become more constructive and help JDBC to solve portability problems, it is the main JDBC goal.

No it isn't. The main goal of JDBC is not to provide portability of querying, it is to provide a standard way of interfacing to a database and finding out what it can do. This is made clear by the number of methods that JDBC provides that allow the developer to test the capabilities and feature support of a database. If JDBC was about portability, those would not be needed.

ORM goal is model transformation and this has nothing to do with portability.

I'm sorry, but this is just not true. ORM most certainly has a goal of portability - it is a primary goal of JDO for example. If they were not concerned with portability they would not have their own query languages.

I don't think anyone ever said it was hard. It is error prone. The exception handling mechanism is, frankly archaic. And it promotes redundacy via boilerplate code.

I fully believe that all aspects of the application is important, but I don't CARE if the DBA likes my tool or not. DBAs make good DBAs, not good programmers. I don't care if my plumber likes my electrical wiring either.

The only people I see making noise about ORM vs JDBC are people who seem to have a chip.

What made Hibernate so successful IMHO, is the use of DBMS-specific dialects from the outset. No more bitching about a 'common denominator'-kind flexibility or performance. It's not that one has to migrate, say, Oracle to Sybase very often; and even if it happens, the cost of porting a well-desinged Java application is likely to be negligible.

JDBC is not ORM, nor it has to be. That's a value proposition of Hibernate and Ibatis. (Sorry if I failed to mention any other fine product.)

A lot can be achieved by simply forcing the vendors to expose their extensions via interfaces (e.g., please make oracle.jdbc.OracleConnection an interface), so that we can write dynamic proxies and whatnot to bridge to their implementations.

OTOH, please don't ignore the vendors: they bring value. Java is not the end of the world.

What made Hibernate so successful IMHO, is the use of DBMS-specific dialects from the outset. No more bitching about a 'common denominator'-kind flexibility or performance.

I think you will find that all decent ORMs, not just Hibernate, have supported DBMS-specific dialects, which allow them to translate their ORM-specific query language (e.g. HQL, JDOQL) into high-performance SQL tailored for each vendor's database.

What made Hibernate so successful IMHO, is the use of DBMS-specific dialects from the outset. No more bitching about a 'common denominator'-kind flexibility or performance.

I think you will find that all decent ORMs, not just Hibernate, have supported DBMS-specific dialects, which allow them to translate their ORM-specific query language (e.g. HQL, JDOQL) into high-performance SQL tailored for each vendor's database.

Perhaps it would be more accurate to say that Hibernate popularized the concepts. For example, I've heard of Toplink for years, but free Hibernate was my first real foray into ORM. Now, the concepts of similar tools have become mainstream.

I think that ultimately, direct JDBC access will be seen as assembly is today...namely, use it when ultimate control and hand-tuned speed is needed, but 95% of the task will be done via ORM.

JDBC is not ORM, nor it has to be. That's a value proposition of Hibernate and Ibatis. (Sorry if I failed to mention any other fine product.)

Like O/R Broker?

Actually, products like iBatis and O/R Broker are not ORM. They are convenience frameworks for JDBC, maintaing the full control of SQL code and execution, while declaratively mapping to objects. JDBC 4 seems to be going in that direction, which makes sense.

On top of that, we used a 'metadata' style database where there are many types of 'entities' stored within one table. So to add an attribute to one of the entities, you simply add a row of data. ORM does not map well to this kind of a system of data that is dynamically defined.

ORM certainly won't help you out of this mess - sound's like you've gotta do lot's of hard coding.

Again with JDBC, this was not a problem. Using ORM *created* problems that we have to work our way around.

Whoever talked you into using a 'generic' database created the problems you have to hard code around.

How do you suppose a Relational Database API will solve the Object-Relational Impedence mismatch?I suppose with a hammer, chisel, and stones we could do without all those convoluted computer thingys as well.

It is very popular to solve "impedence mismatch" problem at this time, it looks like JDBC will solve it again. I hope JDBC will be the most popular and sexy O/R mapping framework, but I expected more than populism from this specification.

I hope JDBC will be the most popular and sexy O/R mapping framework, but I expected more than populism from this specification.

JDBC is not an O/R mapping framework, any more than the Java Sockets API is a web framework. On the contrary, JDBC is highly useful for implementing the database interface aspects of an O/R mapping framework.

JDBC and ORM work very well together - the better the JDBC implementation, the easier it is to produce efficient ORM implementations using it.

JDBC is not an O/R mapping framework, any more than the Java Sockets API is a web framework.

See Query and DataSet stuff in this specification.

JDBC is not an O/R mapping framework, any more than the Java Sockets API is a web framework.

See Query and DataSet stuff in this specification.

Looks like I was wrong! There is now some very simple mapping of objects to tables via DataSet.

However, there is a lot missing from what I would consider a 'mature' ORM - no fetch groups, no transparent persistence, no handling of object references, or Collection types.

However, it looks like the need much of the awful boilerplate code that used to be required in JDBC has been removed. I am impressed.

I like it too, but I expected something like this from EJB 4

I like it too, but I expected something like this from EJB 4

Saying that I like it is going too far :) I can see how it is an advance over JDBC 3.0, but for my purposes it is far from a usable ORM. I would expect an ORM to be able to transparently load and save object which have references to other objects, and contain fields of type List or Map or Tree etc. I want to be able to define lazy loading and fetch groups for efficiency. Without this, you are still in a situation in which database logic is unnecessarily intermingled with business logic. I would also want the ORM to deal with things inheritance.

or ORM = GOOD , JDBC = BAD.
I don't use ORM because of the reasons stated in earlier posts.
The overhead over learning something new and complex, because of restrictions and performance. I have seen similar discussions and the issue is usually bloat versus non bloat.
ORM is bloat. Java is bloat. C++ is bloat an so on.
The frameworks we programmers use are insanely complex even for the smallest tasks. Even so I think ORM is a good thing since it allows to develop for several databases. Nobody can deny the value in that. Especially if performance is not an issue. I mean, an intranet application can break at 3 hits per second and be good enough. So it is bloat. So what?

ORM also allows newly educated people to not to learn SQL. Just relate to objects. For me that is not a sexy thought. It seems many people think so. So it is like putting a hand in a sock. It fits, but it feels strange. But for people that dont't know SQL very well, it is much easier to relate to objects. It is bloat, but it works for them. So it must be good.

My point is bloat seems bad, but it is good.

So what?ORM also allows newly educated people to not to learn SQL. Just relate to objects. For me that is not a sexy thought. It seems many people think so. So it is like putting a hand in a sock. It fits, but it feels strange. But for people that dont't know SQL very well, it is much easier to relate to objects. It is bloat, but it works for them. So it must be good.My point is bloat seems bad, but it is good.

ORM is not intended to prevent people learning SQL. To use ORM well a good knowledge of SQL is essential, as this will allow the developer to analyse how an ORM is working in order to fine-tune use of queries for performance.

I fail to see how ORM is 'bloat'. Considering the huge amount of tedious boilerplate code involved with JDBC, I would say that it is quite the reverse - it helps keep code side small.

So what?ORM also allows newly educated people to not to learn SQL. Just relate to objects. For me that is not a sexy thought. It seems many people think so. So it is like putting a hand in a sock. It fits, but it feels strange. But for people that dont't know SQL very well, it is much easier to relate to objects. It is bloat, but it works for them. So it must be good.My point is bloat seems bad, but it is good.

ORM is not intended to prevent people learning SQL. To use ORM well a good knowledge of SQL is essential, as this will allow the developer to analyse how an ORM is working in order to fine-tune use of queries for performance.I fail to see how ORM is 'bloat'. Considering the huge amount of tedious boilerplate code involved with JDBC, I would say that it is quite the reverse - it helps keep code side small.

With bloat I meant disc, memory complexity bloat. Not code bloat.
If I prefer an approach it does not mean it is the right thing for other people. People have generally a big problem with that idea.

With bloat I meant disc, memory complexity bloat. Not code bloat.If I prefer an approach it does not mean it is the right thing for other people. People have generally a big problem with that idea.

I can't see how ORM involves either disc or memory or complexity bloat. ORM generally involves a few Jars added to an application, and a mapping file or two. Some ORMs set up memory caches to improve the speed of repeated access, but that can be easily turned off. The idea that ORM 'fetches all data into objects' (another source of potential memory bloat) is also false.

I obviously have no problem with peoples preferences. What I respond to is when the publically stated justification for those preferences contains what I believe to be incorrect statements about alternative choices. Examples of this are the repeated claims that ORM is necessarily slow, inefficient, produces sloppy lowest-common-demominator SQL, or results in memory bloat. If an ORM is poorly used then these problems may result, but there are difficulties with any approach to persistence - all the various approaches need care; even JDBC.

With bloat I meant disc, memory complexity bloat. Not code bloat.If I prefer an approach it does not mean it is the right thing for other people. People have generally a big problem with that idea.

I can't see how ORM involves either disc or memory or complexity bloat. ORM generally involves a few Jars added to an application, and a mapping file or two. Some ORMs set up memory caches to improve the speed of repeated access, but that can be easily turned off. The idea that ORM 'fetches all data into objects' (another source of potential memory bloat) is also false.I obviously have no problem with peoples preferences. What I respond to is when the publically stated justification for those preferences contains what I believe to be incorrect statements about alternative choices. Examples of this are the repeated claims that ORM is necessarily slow, inefficient, produces sloppy lowest-common-demominator SQL, or results in memory bloat. If an ORM is poorly used then these problems may result, but there are difficulties with any approach to persistence - all the various approaches need care; even JDBC.

Hehe, I think you misunderstood the last comment. I agree with your points. They are good. And I tried to say in my post that the world of development evolves, So ORM have a place and purpose. For my use i won't consider it just yet,
What i mean with bloat is more like KDE and GNOME is bloat. But it's not unnecessary bloat. It's just a bigger beast.

I do not think ORM can help for "newly educated people", ORM needs query language anyway ( probably the same SQL ). ORM hides trivial SQL like update or find by primary key (save/load) and it adds more complexity itself (configuration,metadata,new API and probably new query language), it makes sence to learn ORM if you transform model manualy and want to automate this task. And it doe's not make sence to use RDBMS if use case is as trivial as save/load a.k.a persistence ( plain B tree can solve it).

I do not think ORM can help for "newly educated people", ORM needs query language anyway ( probably the same SQL ). ORM hides trivial SQL like update or find by primary key (save/load) and it adds more complexity itself (configuration,metadata,new API and probably new query language), it makes sence to learn ORM if you transform model manualy and want to automate this task. And it doe's not make sence to use RDBMS if use case is as trivial as save/load a.k.a persistence ( plain B tree can solve it).

I agree with you. But I think that it is more difficult to get people to learn a new concept than a framework. For me RDBMS seems like a difficult concept to learn if you have no knowledge of it.

For me RDBMS seems like a difficult concept to learn if you have no knowledge of it.

Probably it depends on the way of thinking. I prefer well defined, formal concepts. Probably some people understand analogies better.

I do not think ORM can help for "newly educated people", ORM needs query language anyway ( probably the same SQL ). ORM hides trivial SQL like update or find by primary key (save/load) and it adds more complexity itself (configuration,metadata,new API and probably new query language), it makes sence to learn ORM if you transform model manualy and want to automate this task.

I'm afraid I may be having a problem with understanding what you are saying. I don't understand what you mean by "newly educated people". If it means what I think you mean, then you are obviously wrong, as shown by the phenomenal growth in the use of ORM by newer developers.

Most people use ORM because it is hugely less complex than the endless boiler-plate code that has to be mixed with business logic if JDBC is used. And, of course, re-factoring a large JDBC application can be a nightmare, with all the string-encoded field name table names (although JDBC 4.0 will help to some extent). With ORM the complexity is in one place - the configuration files. With JDBC the complexity is distributed throughout your code.

And it doe's not make sence to use RDBMS if use case is as trivial as save/load a.k.a persistence ( plain B tree can solve it).

The answer is to use an API like JDO 2.0 that allows the same code, along a with a rich query language, to be used even for the most trival persistence case, even outside of RDBMS.

I do not know how "newly educated people" decide to use or not to use some framework and I do not care about it, I just do not think ignorance can help to reduce complexity.

I do not know how "newly educated people" decide to use or not to use some framework and I do not care about it, I just do not think ignorance can help to reduce complexity.

Absolutely. If people are ignorant about the advantages of ORM and how to use it effectively (which does require knowledge of SQL and relational theory), they will end up with more complex software - software that has unnecessary code and barriers to portability.

I do not know how "newly educated people" decide to use or not to use some framework and I do not care about it, I just do not think ignorance can help to reduce complexity.

Absolutely. If people are ignorant about the advantages of ORM and how to use it effectively (which does require knowledge of SQL and relational theory), they will end up with more complex software - software that has unnecessary code and barriers to portability.

Yes, I think you are right. ORM mapps two models and user needs to know both to use ORM effectively.