Implementing it is also difficult for me. It requires some time and a quiet place, which I don't have much right now. Let me know about your progress on it (especially understanding of the way sugar works), I may take a look at the problem one of these days... weeks... months.
Pascal. jabber/gtalk: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] On Tue, Dec 2, 2008 at 01:02, Atsushi Eno <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
