Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

SQLQuery not working

 
Andy Hahn
Ranch Hand
Posts: 225
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, I cant figure this out for the life of me. Any help is appreciated. Using Oracle 11g and Hibernate 3.0.5.

I have the following method in a class named HibernateQueryService:


and I get no results back when I run this code:



The record exists in the table. The query works if hard code the org_id value in the sql instead of using the parameter - "?". Thoughts?
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd sure prefer a means of not having to build a map and list before every single query--to me it looks like you've eliminated the fluent query interface Hibernate provides and replaced it with what it was intended to fix. You also force a null check. Is there a particular reason you've moved all this into a method? This just strikes me as being substantially less clear than just building the query where you use it.

In any case, isn't setFirstResult() 0-based?
 
Andy Hahn
Ranch Hand
Posts: 225
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I'd sure prefer a means of not having to build a map and list before every single query--to me it looks like you've eliminated the fluent query interface Hibernate provides and replaced it with what it was intended to fix.

I think Im stuck using the HibernateCallback for this type of thing, aren't I? How would you do it differently? I'm definitely interested in improving this code and if you can provide an example that would be great.

You also force a null check

You mean the method can return a null so someone would have to do a null check? Isn't that better than returning an empty collection? What's the alternative?


In any case, isn't setFirstResult() 0-based?

Yep I believe so. My example used a 1 for some reason.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andy Hahn wrote:I think Im stuck using the HibernateCallback for this type of thing, aren't I?

For what kind of thing? I not sure if I've *ever* used it, although it's been a year or so.
You mean the method can return a null so someone would have to do a null check? Isn't that better than returning an empty collection?

For me, not really--I'd rather be assured I have an object so if I *forget* a null-check somewhere I won't get an NPE. Other alternatives would include using an exception (which makes sense sometimes, I suppose). This is largely a matter of preference, but doesn't the list() method normally return an empty list? It just seems like you're making Hibernate *harder* to use, not easier.
My example used a 1 for some reason.

I meant is that why it's failing--I don't see anything else obviously wrong, but it's hard to say.
 
Andy Hahn
Ranch Hand
Posts: 225
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For what kind of thing? I not sure if I've *ever* used it, although it's been a year or so.

For working with a SQLQuery object. Since createSQLQuery() is a method on session and not HibernateTemplate. My understanding is that I should to use HibernateCallback any time I work with session directly.


This is largely a matter of preference, but doesn't the list() method normally return an empty list? It just seems like you're making Hibernate *harder* to use, not easier.

Yes but I never liked the fact that Hibernate returns an empty collection - to me its like code that returns an empty String. I guess it just bugs me when code instantiates an unnecessary object. I also have a habit of checking nulls all the time. But I def see your point.

Im not sure why the parameters are not working. Maybe its a Hibernate bug in this particular version. I'll keep looking and let you know if I come up with anything. Thanks for looking.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't see why; like I said, I've rarely (if ever) used callbacks, and I've definitely used SQL queries. I'm not saying don't use it, I'm just saying it's not necessary.

I'd be pretty surprised if there was a Hibernate bug that prevented a simple query like this from working--I've sure never run across it.

If I were doing it I'd try it without all the callback stuff, check out the generated SQL, and so on. (I'd also follow up with a post showing your query and the results straight to the DB to show *us* that the data actually exists, that the second item in the result set actually exists, etc.)

Object instantiation is *cheap*. Checking for null-ness vs. checking for empty-ness will essentially never be a performance issue. Since the object is already created it's *more* work to check for an empty list and return null... (And not using a null-safe empty check and no tertiary expression just adds extra lines of code :)

Like I said--not really a technical argument except for the safety of knowing something isn't null--just a preference.
 
Andy Hahn
Ranch Hand
Posts: 225
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I got rid of the HibernateCallback stuff and it works now. I don't think I would even need HibernateCallback since my Daos are wrapped by Service classes which are @Transactional.

I ended up also shortening my code to just return sqlQuery.list(). That slimmed down my code several lines.

Thanks for the advice!
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm, that's interesting--I wonder why? I'll have to take a look at this when I have a chance.

Glad you figured it out though!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic