Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Validating collections
 

Pages: 1
LLBLGen Pro Runtime Framework
Validating collections
Page:1/1 

  Print all messages in this thread  
Poster Message
davidsidlinger
User



Location:
Nashville, TN, USA
Joined on:
12-Mar-2007 18:23:59
Posted:
17 posts
# Posted on: 23-Jun-2008 17:27:26.  
We are writing a validator that verifies an entity has at least one child entity in a collection. We would like to handle the case where the child collection is not fetched. Is there a way to determine what prefetch paths were used when fetching the entity?

We are using 2.6 with SQL Server/.NET 3.5.
  Top
goose
User



Location:
Central America
Joined on:
06-Aug-2007 18:21:05
Posted:
388 posts
# Posted on: 23-Jun-2008 19:54:29.  
I think that know the prefetchPath used is not that easy. However, you could override this method to see how many childs are fetched in:

Code:
protected override void OnValidateEntityAfterLoad()
{
    base.OnValidateEntityAfterLoad();
}


gansodesoya  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37644 posts
# Posted on: 24-Jun-2008 10:26:17.  
It's an old discussion. the main problem is how 'Customer.Orders' is seen: is it part of Customer, or is it a container not part of the entity customer?.

We do the latter, so you can also fetch the last 10 orders into that container, although it might look like it's the metaphore of 'all orders'. If we would go the route of 'orders belongs to customers' we also have to store exactly which query was used to fetch it. Because, if you see that customer.Orders is empty, and it was fetched, does that mean it was fetched but there was no data, or because there were no entities matching a given filter? So you need the filter as well, which is harder to parse for you than you might think.

As you write the code fetching the data, you know when data is fetched and therefore can take action there, instead of checking after the fetch took place, way later, to see what the fetch actually resulted in.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.