Atsushi, Regarding DbMetal, it should generate: - System.Data.Linq.EntitySet<> and Ref<> for Mono - DbLinq.Data.Linq.EntitySet<> and Ref<> for MS.NET. Any other code generation is a bug.
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). Pascal. jabber/gtalk: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] On Fri, Nov 28, 2008 at 07:53, Atsushi Eno <[EMAIL PROTECTED]> wrote: > > Bonjour Pascal, > > Pascal Craponne wrote: > > in theory, DbLinq should only use its own EntitySet<> and EntityRef<>. > > If a non-DbLinq class is present somewhere in test code, this is a > > mistake. DbLinq probably still supports in the core a bit of MS > > EntitySet and Ref to keep a bit of compatibility, but we may also drop > > those parts in the future. > > OK, I've found the code that created System.Data.Linq.EntitySet<T>. It > was Northwind.cs :/ Probably it is automatically generated by DBMetal? > > Actually when I replace them with DbLinq.Data.Linq.EntitySet, it seems > to get into some infinite loop. I'll dig it in depth later. > > > Regarding eager loading, nothing appears to be in progress (I haven't > > heard from Pablo for a while, by the way). I can develop my architecture > > idea about this if you are interested. > > That'd be great :) (And I am also not sure if Pablo is still alive.) > > > Anyway, the following remaining tasks are related and should be solved > > together: > > - complex subexpressions > > - eager and lazy loading (lazy loading currently works, but I'm not sure > > it fits in the global idea) > > Right, they are tied together. > > > However I haven't been giving DbLinq much time last month (apparently > > I'm not the only one), so all of this is in standby mode. > > Yep, while I haven't seriously worked on dblinq until this month ;-) > > 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 -~----------~----~----~----~------~----~------~--~---
