If you set the load options to eager load, it is logic for the DataContext to perform a join between children and parents. Try doing context.Parents.Select() and context.Children.Select() separately and adding them on your own. This way, it will perform 2 seperate queries as you are looking for.

But out of curiosity, why do you want to perform a retrieve both on children and parents and not do a join ? What’s the requirement ?

Thanks,

Sidar

I ran SQL Profiler against a LINQ query similar to the one shown in your GetQuestion() implementation. The generated sql is a join of the parent/child tables producing a single result set. A row will be returned for each child and that row will include the parent info as well. Sending the parent info over with each child seems unnecessary. Is there a way to have LINQ generate multiple queries for a parent/child relationship?

Something like …
select * from parent where parent_id = 1
select * from child where parent_id = 1

Thanks,
Chris

After our conversation with the mail, did the point I suggested work ? If it did, could you post it here?

Thanks,

Sidar

I’ve been using your blog post as a guide to implementing POCO with LINQToSQL in my own solution, but am having some troubles with nested list.

Would it be possible for you to have a look at my StackOverflow question and pass on any guidance you can?

It would be muchly appreciated as I’m now at the point of pulling my hair out.

Regards,

Matt

http://stackoverflow.com/questions/298162/help-needed-for-linq-to-sql-operations-insertupdate-with-nested-pocos

Lately I have been spending a lot of time with that and bumping into the limitations of L2S development discrepencies. I will also discuss them in another blog post, but bear with me, I am close to there

Yes I did check out - It is a code generator, which generates another layer of mapping. Please see my response in the above comments to Rob on another layer of mapping.

On top of them, EF is already very heavy with 2 levels of mapping, adding 3 rd level to this stack where I just need 1 level is an overkill and overhead. It is not a solution to the problem, it is just a *workaround*. And a work around that has all the problems inherently from code generation perspective, e.g source control nightmares, maintaining untested mappings, loads of classes that are not used, being bound to the generation technology etc. The more layers you are away from ORM’s Context, less you get the goodies of it or depend on generation to get them - why would I, when I don’t need to increase the distance ?

I still need to regen my Adapter layer and Proxies for lazy loading when a change occurs in the db, it is inevitable. So no positives on that side either. (btw, the amount of mapping you need to regen when db model changes in EF is already tremendous, not to mention the poco adapter). L2S is very easy and provides lots of flexibility in this context, does what it needs to, doesn’t what it can’t do good.

On the other hand, I will keep an eye on your blog and already looking forward to the posts. Thanks for the comment.

Have you checked out EFPocoAdapter? Its something (http://blogs.msdn.com/jkowalski/archive/2008/09/09/persistence-ignorance-poco-adapter-for-entity-framework-v1.aspx) that will allow you to utilize EF and work with POCO objects. I have successfully used in in a number of projects and architectures. I am planning on doing a 6 Series blog post on how to use it and setup, etc. Give it a shot, and be on a lookout for my blog posts on this.

It just seems that once you have it setup, there is no need to manually regen xml or code files by using this approach.