Hello,

Pascal Craponne wrote:
> Atsushi,
> 
> Regarding DbMetal, it should generate:
> - System.Data.Linq.EntitySet<> and Ref<> for Mono
> - DbLinq.Data.Linq.EntitySet<> and Ref<> for MS.NET <http://MS.NET>.
> Any other code generation is a bug.

OK. I have changed Northwind.cs to use DbLinq.* types so far.

> Regarding the architecture, this is a rough idea, I'm haven't been 
> diving into sugar's code for a while.
> Here it is:
> - There is a new EntitySetExpression type (I don't like much the name, 
> but had no better idea).
> - Currently it is disabled (ExpressionDispatcher.Analyzer.cs, line 658), 
> and should be enabled to allow the eager loading (well, after 
> implementation).
> - Then the hard part:
>   - When translating to SQL, the point is to register the KFs, even if 
> such columns are not required by the linq expression.
>   - In the row creator, or before (this is the most blurry part in my 
> plan), then the entity needs to be linked to the parent, using the FKs 
> (which allow to identify the parent in a unique way).
>   - The row creator must also be changed, to be sure that the parent 
> entity is created only once. Same trick, we use the FK referenced by its 
> child to know that it already exists
>   - This must work recursively, of course (we can have a lot of nesting 
> levels)
>   - When translating for CLR side, the EntitySetExpression probably just 
> needs to be ignored, and removed (I'm not sure of this).
> 
> Anyway, we will get the problem for Skip() and Take(), because we won't 
> be able to translate this to SQL, since because of children, we can not 
> guess the exact number of rows to skip and take.
> So we have a hard side effect, where we will need to skip and take in 
> the row creator, for such cases (anyway, some database probably require 
> the same thing, since not all of them allow th skip and take in SQL).

OK, I sort of understand the problem, but also I find difficulty in
drawing the picture on how to implement it. I'll dive into both
sugar and ado.net things. My wild guess is that L2SQL would prohibit
such cases that it cannot find FK or something for associations.

Atsushi Eno

--~--~---------~--~----~------------~-------~--~----~
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