cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Lindesay <...@lindesay.co.nz>
Subject Re: New features in Select API
Date Wed, 08 Apr 2015 01:10:03 GMT
Hi Michael;

That also seems like a good option.

Regards;

On 8/04/15 6:31 am, Michael Gentry wrote:
> I could see having a requireOne() method that throws an exception if there
> isn't exactly one match...
>
>
> On Tue, Apr 7, 2015 at 2:15 PM, Andrew Lindesay <apl@lindesay.co.nz> wrote:
>
>> Hello Savva;
>>
>> Thank you for that update.  I had some thoughts on the "selectOne"
>> interface.
>>
>>> selectOne(ObjectContext);
>>>
>>
>> I often find myself needing to assert that a single object is present
>> after querying for it.  A good example would be querying for an item of
>> reference data by some 'code'.  In this example there are three
>> possibilities;
>>
>> 1) I get nothing --> runtime exception
>> 2) I get one object --> return it
>> 3) I get more than one object --> runtime exception
>>
>> The "selectOne(..)" method will (as-built) take care of dealing with the
>> #3 runtime exception for me, but still leaves me to handle the runtime
>> exception for #1.  I wonder if...
>>
>> T selectOne(context)
>>
>> ...should throw a runtime exception if it finds no result instead of
>> returning null.  An additional signature...
>>
>> T selectOne(context, T fallbackValue)
>>
>> Could take a fallback value that could be presented in the case that the
>> query yielded no results.  This would provide the functionality
>> as-implemented now.
>>
>> Although it is not an option because of the language level of the project,
>> returning an Optional<T> (Java 8 / guava) would also provide a good way to
>> provide this functionality.
>>
>> Regards;
>>
>> --
>> Andrew Lindesay
>>
>


-- 
Andrew Lindesay

Mime
View raw message