In the latest release of 2.1, I added the Query.result() method:





I really like this now (should have done it ages ago), and I have a couple of questions:


(1) At present, result() throws an exception if there are no results from the query (and also, of course, if there is >1 result). Should it return null instead?

(2) Should I add a result() method to the Session interface, ie:




(3) If so, should I rename it uniqueResult(), for clarity ?



P.S. in the next implementation, I plan to auto-distictify the results, so that you can do:



And have it not throw an exception. This will be useful.

1. Absolutely make it return null, instead of throwing an exception. Exception are expensive, and somewhat annoying to handle in the code.
2. No comment.
3. No comment.

4. Please consider making Session.load() return null instead of throwing ObjectNotFoundException, for the same reason as above.

Thanks,
Nils

1. Return null if there are no result from the query.

2. Yep.

3. Yep.

Regards, Andreas

1. I'm leaning towards throwing an exception!

Returning null when the result is higher than it should be, is in my mind VERY dangerous! It makes no error occur when their actually should. But returning null when the result is really empty is quite alright.
And we cannot "swallow" all other exceptions, so one still need to handle database errors, error in query etc.
Thus I find it very usefull to have the explict exception (NonUniqueResultException if I remember correctly), because then you could simply just ignore that exception in user code.

If users want the more "I hope everyone is aware this might fail, but i don't care" feature they can easily just mimic the code in result() - it is very simple code.

To be nice we should add the explict exception to the throws list - just to document it more explicitly!

2. I lean forward to yes - but not because every method in Query should be available in Session, but because this result method is a helper method that should remove the "overhead" of finding a single result from a list. Having result() on Session will make it easily available - and thus I prefer even more it is strict regarding exceptions.

3. I was "baffled" by the name when I saw it. result() to me, is "way" bigger than a single result. uniqueResult() is better, what about singleResult() ?. We should also consider if uniqueResult() makes people relate it to the unique keyword in SQL - maybe indicating that they get a list of all unique records instead or something like that....but that is probably not the case ;)

(nb. if for some very weird reason ;), we choose to return null we should find another name as uniqueResult() would be "wrong" here. )

4. (to Nils) No way regarding load() - it is a plus that we do not hit the db in load as it let us assign simple foreign object to another object without any penalty ;) The behavior you want is easily accessible via find() and the new (unique)result() method.

1.
I would throw an Exception if more than one record is found (this obviously abnormal and should never happen if the database is consistent - 'cause of the unique primary key).

If nothing is found, I would return null. This is not an error but something usual: there is simply no record matching the criteria.

2:
No comment

3:
No comment

in the event of multiple results, would it be reasonable to (maybe optionally) return the first found result? This is already the behavior of the =(cast)sesison.iterate().next() idiom.

maybe query[..blahblah..].oneResult(int nthItem), Like the .next idiom, except returning null if there is no nth element instead of pitching a noSuchElement exception, and oneResult() defaults to oneResult(0)?

by all means if this is a bad idea, tell me. I'm no expert.

It is a better method name and the nthItem parameter "forces" the user t o decide what they want and also makes it explicit what the method does.

So my stand are:

1. if it is uniqueResult() we want, it should throw an exception
2. if we don't want to throw we should make it something like oneResult(int nthItem)
3. I like 1. better than 2., but 2. is ok if 1. is also there. Why? because I would much rather want my co-developers use 1 to explicit say this stuff should only return 0 or 1 item - and if it does not we throw an exception.

Let me clarify:

1. On no object, return null, on multiple objects, throw exception.

2. Since it's similar to find(), why not call it findSingle() or findObject()?

Max, please pardon my newbiness -- can you explain or give an example of when you would use load to "assign simple foreign object to another"? Does this mean that "load" is retrieving the object from the cache if available?

TIA

Gavin,

IMHO and as I understand it:

(1) If the method is supposed to return nothing or one result (hence it's called uniqueResult()), then it should return null if nothing is found and an Object if something was found. If more than one thing was found, throw an Exception, because that's exactly what it is: an unexpected result.

If you decide to rename the method to .firstResult(), then the user would be aware of that no matter how many results the query returned, the method would return null or the first object in the result. Here it would make sense for me to not throw exceptions.

I agree that it's easier to check for a null value than to catch an Exception, but Java has a very good Exception handling system and it makes so much sense that we shouldn't ignore it.


(2) It would be an useful shortcut.

(3) Sure. Not only in the Session class, but also in the Query class (make .result() deprecated and create .uniqueResult()).


Those are my 0,03 cents.

[quote="bsiggelkow"]Max, please pardon my newbiness -- can you explain or give an example of when you would use load to "assign simple foreign object to another"? Does this mean that "load" is retrieving the object from the cache if available?

[/qoute]



If child has a foreign key to parent the above load of Parent will not require any access to the db - you can just save the Child and it will have it's foreign key set - very effective for an ORM!

(The above require the Parent to be mapped as a proxy)



[/code]

We wouldn't need to deprecate result(), it only appeared in the most recent beta. I reserve the right to change the name of things until they go out of beta!

Hmmm ... I think I had been addressing that situation doing something like this:

Is that incorrect? What are the benefits of the session.load() approach? One I can see is that I need not a constructor that takes the ID.

1) Multiple objects should definitely throw an exception. For no objects I can see arguments for both exception and null, but am leaning to null (I have a similar method called PersistUtils.expectZeroOrOne(Query))

2) Probably.
3) Probably.

Chris

That is incorrect in my world ;) It does not result in an error I assume (since you are doing it ;)

The benefit of load() is that the loaded object(here a proxy) will be associated with the sesssion - so if you do start to accesss the properties of the parent (or load or find it later in the same session) you will get the same instance.