According to the article, this is supposed to opeate as a "fairly thin layer that sits on top of JDBC" that "queries relationsal databases as well as Java collections and database caches." It works with any database that has a JDBC driver and plays well with Spring and iBatis.
My question is simple: Has anyone played with this yet, and if so, is it real? The article doesn't mention any drawbacks.
Hmmm... I don't know much about JPA. Another article from their DeveloperWorks site may answer that. They say:
Such solutions (HQL/JPA's JQL and others) hide the actual native SQL from the developers and DBAs since these queries transform themselves into the native query languages at runtime. An inherent problem with such solutions is that developers have less visibility to the efficiency of the generated SQL, thus making problem determination more difficult. Resulting applications built using such products are rigidly tied to a single vendor query language. Often times the proprietary query languages are not sophisticated enough to handle more complex scenarios and queries.
I printed it out to read on the train. 48 pages (landscape), so I'm not through yet. This article contains a lot of illustrations of examples of working with it in Eclipse.
I e-mailed the author of the DB2 magazine article I posted originally. I couldn't find it available for download anywhere. He said it will be available for download at the end of this month. He offered me a beta if I wanted it right now, but since it is only a few days out I declined his kind offer and said I'd wait for the final release.
The "pure" prefix must be something new with IBM. First it was pureXML, now it's pureQuery. Kind of leaves them open to flame, doesn't it? "This product is pure(you-know-what)", etc. [ October 23, 2007: Message edited by: Charles McGuire ]
Charles, I agree with that paragraph. However pureQuery appears to have all those limitations as well.
There is an inherent problem here. Relational databases understand SQL. Which means we either need to write SQL or write in a language that is translated to SQL. The longer article explains that they do in fact use SQL. It looks like there main benefit is providing an IDE. I still think the biggest drawback is that you are locked into their API. And I still think that they would have been better off providing an IDE for a standard.
Joined: Jan 18, 2005
As developers, we use API's all day long. I'm not too worried that this may be proprietary as there are different levels of proprietary, some worse than others. The gain will have to exceed the pain.
I didn't realize when I posted the original question that pureQuery wasn't available for download yet. We'll have to see the EULA when it becomes available at the end of the month, plus all of the functionality.
My predisposition is kind of anti-framework bloat. I don't know if this plays to that predisposition or against it. It will be something to play with on a rainy weekend.
Originally posted by Charles McGuire: as there are different levels of proprietary, some worse than others. The gain will have to exceed the pain.
I agree with that. We certainly use our share of proprietary frameworks!
The difference is that we use it when there isn't a non-proprietary alternative available.
Joined: Jan 18, 2005
Jeanne, Sometimes I wonder if these kinds of debates will be at all relevant in five years. E-week magazine reported this from the OOPSA conference a few days ago:
Speaking on the move to solid state memory, Gosling said that "the real notion of what will change is databases. I say data structure, not database. Why do you want to use a database? Just use RAM. With the machines we make, you can put half a terabyte of RAM on them. And you don't use databases, you use RAM and things run like the wind."
From an OLAP perspective, even if it lives in some type of memory cache... it would still have to have some type of structure for it to be useful to the business... RAC is Oracle's progression towards this.
I'm not sure if I completely understand Gosling's statment... maybe he is just looking at this strictly from an OLTP application viewpoint.