Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

pureQuery(tm)... What are the drawbacks?

 
Charles McGuire
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now that the craziness of the book giveaway is over, I have a question about a rather intriguing looking product.

http://www.db2mag.com/story/showArticle.jhtml?articleID=202400140

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.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34837
369
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Charles,
Thanks for posting this after the promo so it gets more attention and thoughtful replies .

I haven't used it, but I'm a bit skeptical. They say "but it isn't just another SQL-like language." This looks plenty SQL like to me:


In fact, the whole description sounds a lot like JPA.

It doesn't force you to use a specific API (such as EJB2, JPA, Spring, or iBatis), but it does facilitate the implementation of several existing APIs for accessing data.

Gotta love the marketing speal. It doesn't force you to use a standard API like JPA. Instead, it forces you to use a whole new IBM specific API. This reeks of vendor lock in to me.

I can see their selling point of an IDE for SQL. They support JPA. I don't see why this can't just be JPA rather than another layer of abstraction around it.
 
Charles McGuire
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jeanne,

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.


There is a lot more. The full article can be found at http://www.ibm.com/developerworks/db2/library/techarticle/dm-0709surange/

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 ]
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34837
369
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Charles McGuire
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jeanne,

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.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34837
369
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Charles McGuire
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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."


Full article at: http://www.eweek.com/article2/0,1895,2206130,00.asp


We'll be relaxing at a Starbucks drinking a latte (that will cost twenty dollars by then) and be laughing about those irrelevant JDBC and SQL debates.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34837
369
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting. Wouldn't we still have to read the data from somewhere to get it into RAM?
 
Charles McGuire
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Solid state RAM, Jeanne!

http://en.wikipedia.org/wiki/Solid_state_drive
 
Paul Campbell
Ranch Hand
Posts: 338
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Charles McGuire:
Solid state RAM, Jeanne!

http://en.wikipedia.org/wiki/Solid_state_drive


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.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34837
369
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Charles McGuire:
Solid state RAM, Jeanne!

http://en.wikipedia.org/wiki/Solid_state_drive

Cool! That's an interesting link.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic