Entity Framework .Include does not support paths with more than 8 dot-separated names

I've opened a bug on Microsoft Connect for this, but no response (see edit below for their response) in a long while. So here it goes:

When trying to request an entity framework with its relation using the "Include" function in the linq query, it's impossible to request a relation through a path of more than 8 steps (8 . dot characters in the path). This prevents me from completing some of my dynmically generated queries that require access to more than that level of redirection.

Instead of completing the query successfully I get the following exception:

"Foo.Bar.Baz...(some more path string here)", the current limit of "8" is insufficient.

at System.Data.Common.MultipartIdentifier.IncrementStringCount(String name, String[] ary, Int32& position, String property)
at System.Data.Common.MultipartIdentifier.ParseMultipartIdentifier(String name, String leftQuote, String rightQuote, Char separator, Int32 limit, Boolean removequotes, String property, Boolean ThrowOnEmptyMultipartName)
at System.Data.Objects.Span.Parse开发者_如何学JAVAPath(String path)
at System.Data.Objects.Span.Include(String path)
at System.Data.Objects.Span.IncludeIn(Span spanToIncludeIn, String pathToInclude) 

Has anyone figured why this is so, or a way around this? Looking at the code (with Reflector) of ParsePath it seems that they hard-coded the magic number 8 in there...

UPDATE: Microsoft's response:

Thank you for raising this issue. We plan to remove the limit of the number of elements in an Include path in the next release.

UPDATE 2: Despite Microsoft's response quoted above, the bug was not fixed in EF 4.1

UPDATE 3: According to Microsoft, should be fixed in .NET 4.5, but I didn't test the developer preview to see if it works.

probably fixed in latest .net 4.5 https://connect.microsoft.com/VisualStudio/feedback/details/640423/entity-framework-include-strings-are-arbitrarily-limited-to-a-path-of-depth-8#tabs

I have not seen this, but here are 2 possible work arounds:

• Loop through the data and use Load for each row. Note this will create a call to the database for each row, so it is really slow.

• Flatten the data in a view and then select from the view. This creates a lot of redundant data, so more memory and network use.