CSLA: Record Not Found Behavior

[GoogleCodeExporter]

The EditableRoot (and probably others) are friendly (if dr.Read()) for not
throwing an exception when no records are returned by a DataPortal_Fetch
call. In fact, this may be necessary for binding (?), but how does one
determine whether anything was returned w/o an exception?

     Invoice invoice = Invoice.GetInvoice("bogusID");

The resulting invoice object isn't null, IsNew = false, IsDirty = true...
so it's not like calling the New factory method either (where IsNew = true,
etc).

It's been a while since my head is been in the CSLA-game. So long that I'm
not sure what the Lhotka-ordained behavior is these days for this scenario.

In the 2008 Business Objects book on pg 565 (Chapter 18 - Example Data
Access), he seems to indicate that the intent is for the SqlException to be
thrown, get wrapped in a DataPortalException that is bubbled to the UI, and
the UI has to catch this. In order to make it more friendly, he
demonstrates an Exists static factory method (w/ underlying CommandObject
pattern - pg 579) so that the UI can first determine the existence of an
object/key without instantiating it...

The Exists method would be an added convenience, but I believe in most
cases getting a new object back (and knowing to check the IsNew property)
would be reasonable.

Lhotka, Rockford. Expert C# 2008 Business Objects. New York: Apress, 2008. 

Original issue reported on code.google.com by jprice5...@gmail.com on 22 Oct 2009 at 2:55

[GoogleCodeExporter]

Original comment by bniemyjski on 22 Oct 2009 at 6:40

• Changed state: Accepted
• Added labels: Framework-CSLA, Type-Defect, Priority-High

[GoogleCodeExporter]

Hello,

We will be fixing this issue before the next release.

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 30 Oct 2009 at 5:48

• Added labels: Priority-Critical
• Removed labels: Priority-High

[GoogleCodeExporter]

Original comment by bniemyjski on 6 Nov 2009 at 7:59

• Changed state: Started

[GoogleCodeExporter]

Hello,

I have fixed this in revision 1200 to throw an exception as outlined in the 
book as 
well as in the discussion located in the following forum 
(http://forums.lhotka.net/forums/thread/12301.aspx). 

You should now see an error with extra information like: The record was not 
found in 
'Category' using the following criteria: [CategoryId] = 'bogusID'

If you wish to have your BO return null, we can start a discussion for this in 
the 
forums :).

I have also logged the Exists Request as issue 221 
(http://code.google.com/p/codesmith/issues/detail?id=221).

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 30 Dec 2009 at 1:54

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by bniemyjski on 23 Feb 2010 at 11:34

• Added labels: version-2.0

[GoogleCodeExporter]

Original comment by bniemyjski on 24 Feb 2010 at 11:45

• Changed state: Accepted
• Removed labels: version-2.0

[GoogleCodeExporter]

Does this change really make sense for Collections/Lists?  I understand having 
a root 
business object throw an exception if it does not exist.  But having empty 
lists is 
often a valid scenario.  Currently I'm wrapping all my list Gets() with an 
exists, but 
that executes an extra query.  To me, it would be perfectly fine for GetAll() 
to return 
an empty list.

Original comment by Batku...@gmail.com on 27 Apr 2010 at 12:16

[GoogleCodeExporter]

Hello,

I'd tend to agree, what is the general consensus on this? Can you create a 
forum thread 
on this?

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 28 Apr 2010 at 10:03

[GoogleCodeExporter]

I agree. It was not my intent to suggest the RecordNotFoundException/request 
apply to
collection-based objects. I only intended to point out out that with the 
then-current
behavior it was not possible to determine whether a record was found or not 
because
it returned an object (not null) and that object's IsNew property was false.

It's perfectly reasonable for any collection-based object's emptiness to be 
defined
by Count = 0. In fact, in cases of children collections it'd have to be that 
way (I'd
think) to be of any practical use. You wouldn't want your child collection
recordnotfound bubbling to the parent merely because there was no related child 
records.

Original comment by jprice5...@gmail.com on 28 Apr 2010 at 10:17

[GoogleCodeExporter]

Hello,

Do you think that if you specify no criteria then it should never throw an 
exception if 
no data is returned but if you specify criteria and no records are returned 
then it 
should throw an exception?

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 20 May 2010 at 5:06

[GoogleCodeExporter]

From my perspective it should never throw exception.  Reasoning is that an 
empty list 
is still a valid object.  Queries like "give me all the invoices over $1000" 
for 
instance should not throw an exception the list is empty because I can't know 
the 
answer before hand and therefor forcing me to always call Exists.

Original comment by Batku...@gmail.com on 20 May 2010 at 7:23

[GoogleCodeExporter]

I agree completely with previous comment #11 by tho...@mirrin.net. Since that 
exceptions has added, I must remove it from templates by hand from all new 
versions. 
For lists, the correct approach (with or without criteria) must be to check the 
count property of the object list returned.

Original comment by bernyrod...@gmail.com on 24 May 2010 at 5:01

[GoogleCodeExporter]

I agree completely with previous comment #11 by tho...@mirrin.net and #12 by 
bernyrodrigo. Blank child lists are valid.

Original comment by JenasysD...@gmail.com on 25 May 2010 at 12:03

[GoogleCodeExporter]

Hello,

I tend to agree with this. I went off what the book states and what rocky 
recommends. What if we said that if you pass in 0 criteria (GetAll) than we 
will not throw an exception. However, if you are querying for something 
specific than it should throw an exception? 

This may be kind of confusing.... Can any one think of a few good reasons why 
we would want to throw an exception and keep this behavior?

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 19 Jun 2010 at 9:15

[GoogleCodeExporter]

Blake, I believe that all the time, the forum thread are refering to single BO, 
and never talks about collection based BO's. I think that it is very positive 
to trow exception on single BO but it is very inappropiate in lists because you 
can't catch the exception on UI.

Furthermore, although it is true that Rocky talk about the possibility of 
include the throwing exception approach, I can't find any of his samples that 
throw that exception in DataPortal_Fecht methods, neither first SQL dataaccess 
samples, nor linq dataaccess samples.

Original comment by bernyrod...@gmail.com on 19 Jun 2010 at 11:16

[GoogleCodeExporter]

Note: I refer to the follow forum thread 
(http://forums.lhotka.net/forums/thread/12301.aspx)

Original comment by bernyrod...@gmail.com on 19 Jun 2010 at 11:19

[GoogleCodeExporter]

FWIW, I agree that empty child lists are valid.  Happens *all* the time.

Original comment by bill.n...@gmail.com on 22 Jun 2010 at 3:43

[GoogleCodeExporter]

Hello,

I'm currently asking Rocky for clarification. I found the following two posts 
(http://forums.lhotka.net/forums/p/1251/6519.aspx#6519 and 
http://forums.lhotka.net/forums/p/6936/33249.aspx#33249). That talk about this.

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 22 Jun 2010 at 5:32

[GoogleCodeExporter]

Hello,

I talked with rocky and will be making this change!

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 25 Jun 2010 at 6:21

• Changed state: Started

[GoogleCodeExporter]

Original comment by bniemyjski on 25 Jun 2010 at 9:31

• Changed state: Fixed
• Added labels: Version-3.0.0

[GoogleCodeExporter]

This issue was updated by revision r1743.

Fixed Issue 179: CSLA: Record Not Found Behavior    

Original comment by bniemyjski on 25 Jun 2010 at 9:31