I've studied a bit the problem.

Given Customer and Order where exist Customer.Orders (EntitySet<Order>) and
Order.Customer (EntityRef<Customer>):

Order.Customer, before being accessed should contain the customerID and a
lambda able to query the dataContext for providing the Customer.
Customer.Orders, before being accessed should contain the customerID and a
lambda able to query the datacontext for providing the Orders.

Both need a (non serializable) reference to the DataContext.

When the EntityRef.Entity is firstly accessed, the lambda is invoked on the
datacontext providing (and storing in a private field) the concrete entity.

EntitySet should do the same where any of it's properties is accessed.

Strangely no public constructor take an expression, but I could suppose that
there are private ones for this.

When invoking add or remove entities from entity set should act properly
upon the datacontext.



Am I missing something about this?
(It really could be, since I'm also working on a Domain Model with similar
but different problematics)


Giacomo



1. When Entity EntityRef should contain the value of the referencing key
(often the id of the referenced entity) and

On Tue, Apr 14, 2009 at 11:53 AM, Pascal Craponne <[email protected]> wrote:

> Well, let's try :)
> 1. First of all, lazy loading means that after the first load, all entity's
> EntitySets and EntityRefs are empty.
> 2. The first time they're used, we want them to actually load the
> referenced entities and keep them for further reference.
> 3. Next, when using EntitySets and EntityRefs, we get a fast access to the
> referenced entities, because they're already loaded.
>
> Until here, I think we all agree.
>
> So now, let's see each point in details.
> We start from point 2, where the effective loading is done.
> The EntitySet or EntityRef needs:
> a. A foreign key referencing the entities to be loaded.
> b. A reference to the table
> c. A reference to the DataContext, or something like this.
> Once invoked when unitialized, the EntitySet/Ref just performs a request on
> the foreign keys to load the entities.
>
> Now let's move to point 1.
> When an entity is loaded for the first time, its EntitySets and Refs are
> initialized with the foreign keys and all necessary information to perform
> lazy loading.
>
> Point 3 is no problem at all.
>
> So our EntitySet/Ref can be initialized in two ways:
> - providing the entities (to allow eager loading, or current system).
> - providing the foreign keys and all required information.
>
> But, of course, this would be too simple, since there are a few problems to
> handle:
> - mutual reference: an entity referenced with an EntitySet also has an
> EntityRef to its referencing entity (am I clear?). We need to be sure that
> all links are correct. This should probably work without any change thanks
> to the cache.
> - correct use of cache (Giacomo, I know you are fully concerned with this
> :). This should work correctly if we reuse the DataContext.
> - DataContext lifetime. When using lazy loading, we imply that the
> DataContext is keep somewhere, so we may change its lifetime when used in a
> service architecture. Worse, we could get problems when the DataContext
> connection is closed. This is usually why lazy loading isn't allowed from
> outside a service call, because the connection and transactions are closed,
> and lazy loading can not be performed anymore.
>
> There may be some other problems, but I dumped here all the ideas I had at
> the moment :)
>
> Pascal.
>
> On Tue, Apr 14, 2009 at 11:11, Giacomo Tesio <[email protected]> wrote:
>
>> Mmm... Do you know where I could work for implementing a correctly working
>> lazy loading?
>>
>> Yet I've no complexive view of the source code, so any input is welcome.
>>
>> I saw Pablo worked on EntityRef and EntitySet but I've not yet idea of the
>> difference.
>> Could you explain me?
>>
>>
>> Giacomo
>>
>>
>> On Tue, Apr 14, 2009 at 10:59 AM, Pascal Craponne <[email protected]>wrote:
>>
>>> As far as I remember, it's neither eager or lazy.The linked entities are
>>> loaded after the requested one are processed, and this, recursively.
>>>
>>> This is not eager because there are multiple requests to get all the work
>>> done.
>>> This is not lazy because when items are loaded all subsequent entities
>>> are also loaded.
>>>
>>> Pablo implemented this, but he's not very active on the list by these
>>> days :S
>>>
>>> On Mon, Apr 13, 2009 at 23:21, Giacomo Tesio <[email protected]> wrote:
>>>
>>>> Reading
>>>>
>>>> http://groups.google.com/group/dblinq/browse_thread/thread/283191499b74199f
>>>> and
>>>>
>>>> http://groups.google.it/group/dblinq/browse_thread/thread/4a67b172b607b0f9/666ae4667594c828?hl=it&lnk=gst&q=lazy+load#
>>>>
>>>> I could not understand if DbLinq currently support lazy loading or
>>>> not...
>>>>
>>>> Can you help me?
>>>>
>>>>
>>>> Giacomo
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"DbLinq" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/dblinq?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to