EF POCO Adapter updated (v1.03)

car insurance » EF POCO Adapter updated (v1.03)

car insurance » EF POCO Adapter updated (v1.03) — Fri, 26 Sep 2008 06:35:41 GMT

PingBack from http://hoursfunnywallpaper.cn/?p=7912

re: EF POCO Adapter updated (v1.03)

crazydoctoral — Fri, 10 Oct 2008 05:05:44 GMT

Was having trouble with the Generator, until I realised the filenames in the arguments are case sensitive. So classes.Dll failed to work but classes.dll did.

re: EF POCO Adapter updated (v1.03)

CraigCav — Sun, 12 Oct 2008 12:16:29 GMT

I'm having a little bit of trouble when trying to extend this sample with (what I would consider) a reasonable usage. The problem I encounter occurs after extracting an interface from a class in the model (say, Product : IProduct), and causes the TestMethod GenerateAndUsePocoAdapter() to fail.

The error message given is:

Test method NorthwindEF.Tests.AdapterGeneratorTests.GenerateAndUsePocoAdapter threw exception: System.InvalidOperationException: Generated code failed to compile

Errors (32):

(2660,13): CS0506 'NorthwindEF.PocoProxies.ProductProxy.ProductID.get': cannot override inherited member 'NorthwindEF.Product.ProductID.get' because it is not marked virtual, abstract, or override

It also appears that the generated code will fail to compile if one of the model classes implement an interface that exists within another assembly - for example Customer : IAggregateRoot (where IAggregateRoot is an interface that exists in an assembly referenced from the NorthwindEF project).

Riflessioni su Entity Framework v1 e vNext #2

Mon, 20 Oct 2008 19:23:02 GMT

EntityClient Entity Framework != O/RM Sappiamo tutti che il buon vecchio pattern in un ADO.NET Data Provider

re: Problems with type exceptions EF POCO Adapter

jlddodger — Sat, 22 Nov 2008 01:49:58 GMT

I am having trouble performing a certain type of query. The goal of this query is to create an instance of a custom class that contains a member of the query result type (Customer) for each query result.

The most obvious query that worked before we began using the EF Poco Adapters is as follows:

var b = (from r in db.CustomerSet

where r.Name.Contains("AUTOMATED")

orderby r.Name

select new Result()

{

Customer = r

});

However, when enumerating the result of this query, I receive "Argument types do not match".

Okay, so what is the actual object represented by "r"?

{Database.PocoProxies.CustomerProxy}

Okay, so what if I try to receive that object type directly?

var d = (from r in db.CustomerSet

where r.Name.Contains("AUTOMATED")

orderby r.Name

select new Result()

{

CustomerProxy = (CustomerProxy)r

});

This generates "No coercion operator is defined between types 'Database.PocoAdapters.ResellerAdapter' and 'Database.PocoProxies.ResellerProxy'."

Hmm... This is having trouble converting from a ResellerAdaptor, so what if I try to receive this type?... no, that can't work...

var f = (from r in db.ResellerSet

where r.Name.Contains("AUTOMATED")

orderby r.Name

select new Result()

{

ResellerObject = (ResellerAdapter)(IPocoAdapter)r

});

Nope... 'Database.PocoAdapters.ResellerAdapter' to type 'EFPocoAdapter.DataClasses.IPocoAdapter'. LINQ to Entities only supports casting Entity Data Model primitive types.

But that, at least, makes sense...

Okay so here's what makes me go from hmm... to grr...

var a = (from r in db.CustomerSet

where r.Name.Contains("AUTOMATED")

orderby r.Name

select r);

Result res = new Result()

{

Customer = a.First(),

};

This works! By performing the construction outside of the query expression, the types magically work... but then we lose nice features like Deferred Loading, etc... (is this correct?)

But better yet...

var a2 = (from r in db.CustomerSet

where r.Name.Contains("AUTOMATED")

orderby r.Name

select new

{

Customer = r

});

The only difference between test (b)--the preferred method--and (a3) is that (a3) constructs an anonymous class instead of a defined one. But, how then can I add functionality to that class if it is anonymous. That is the whole point of constructing an object instead of meddling with the result directly.

Just to take a stab in the dark. I have witnesses 'Argument types do not match' coming from places where ValidateSameArgTypes fails...

The stack at the exception is (I hope this formats well):

System.Core.dll!System.Linq.Expressions.Expression.Bind(System.Reflection.MemberInfo member, System.Linq.Expressions.Expression expression) + 0xaa bytes

EFPocoAdapter.dll!EFPocoAdapter.Internal.QueryTranslator.VisitMemberAssignment(System.Linq.Expressions.MemberAssignment assignment = {Reseller = r}) + 0x90 bytes

EFPocoAdapter.dll!EFPocoAdapter.Internal.ExpressionVisitor.VisitBinding(System.Linq.Expressions.MemberBinding binding = {Reseller = r}) + 0x97 bytes

EFPocoAdapter.dll!EFPocoAdapter.Internal.ExpressionVisitor.VisitBindingList(System.Collections.ObjectModel.ReadOnlyCollection<System.Linq.Expressions.MemberBinding> original = Count = 1) + 0x9d bytes

EFPocoAdapter.dll!EFPocoAdapter.Internal.ExpressionVisitor.VisitMemberInit(System.Linq.Expressions.MemberInitExpression init = {new Result() {Reseller = r}}) + 0x91 bytes

EFPocoAdapter.dll!EFPocoAdapter.Internal.ExpressionVisitor.Visit(System.Linq.Expressions.Expression exp = {new Result() {Reseller = r}}) + 0x3fc bytes

EFPocoAdapter.dll!EFPocoAdapter.Internal.QueryTranslator.VisitLambda(System.Linq.Expressions.LambdaExpression lambda = {r => new Result() {Reseller = r}}) + 0x77 bytes

EFPocoAdapter.dll!EFPocoAdapter.Internal.ExpressionVisitor.Visit(System.Linq.Expressions.Expression exp = {r => new Result() {Reseller = r}}) + 0x2e0 bytes

EFPocoAdapter.dll!EFPocoAdapter.Internal.ExpressionVisitor.VisitUnary(System.Linq.Expressions.UnaryExpression u = {r => new Result() {Reseller = r}}) + 0x62 bytes

EFPocoAdapter.dll!EFPocoAdapter.Internal.QueryTranslator.VisitUnary(System.Linq.Expressions.UnaryExpression u = {r => new Result() {Reseller = r}}) + 0x29c bytes

EFPocoAdapter.dll!EFPocoAdapter.Internal.ExpressionVisitor.Visit(System.Linq.Expressions.Expression exp = {r => new Result() {Reseller = r}}) + 0xc0 bytes

EFPocoAdapter.dll!EFPocoAdapter.Internal.QueryTranslator.VisitMethodCall.AnonymousMethod(System.Linq.Expressions.Expression c = {r => new Result() {Reseller = r}}) + 0x42 bytes

System.Core.dll!System.Linq.Enumerable.WhereSelectEnumerableIterator<System.__Canon,System.__Canon>.MoveNext() + 0xb9 bytes

System.Core.dll!System.Linq.Buffer<System.Linq.Expressions.Expression>.Buffer(System.Collections.Generic.IEnumerable<System.Linq.Expressions.Expression> source) + 0x1b3 bytes

System.Core.dll!System.Linq.Enumerable.ToArray<System.Linq.Expressions.Expression>(System.Collections.Generic.IEnumerable<System.Linq.Expressions.Expression> source) + 0x52 bytes

EFPocoAdapter.dll!EFPocoAdapter.Internal.QueryTranslator.VisitMethodCall(System.Linq.Expressions.MethodCallExpression m = {ResellerSet.Where(r => r.Name.Contains("AUTOMATED")).OrderBy(r => r.Name).Select(r => new Result() {Reseller = r})}) + 0x135 bytes

EFPocoAdapter.dll!EFPocoAdapter.Internal.ExpressionVisitor.Visit(System.Linq.Expressions.Expression exp = {ResellerSet.Where(r => r.Name.Contains("AUTOMATED")).OrderBy(r => r.Name).Select(r => new Result() {Reseller = r})}) + 0x299 bytes

EFPocoAdapter.dll!EFPocoAdapter.Internal.QueryTranslator.Translate<System.Collections.Generic.IEnumerable<Database.ResellerQuery.Result>>(System.Linq.Expressions.Expression pocoExpression = {ResellerSet.Where(r => r.Name.Contains("AUTOMATED")).OrderBy(r => r.Name).Select(r => new Result() {Reseller = r})}, out System.Func<EFPocoAdapter.EFPocoContext,object,System.Collections.Generic.IEnumerable<Database.ResellerQuery.Result>> adapterFunction = null) + 0x80 bytes

EFPocoAdapter.dll!EFPocoAdapter.EFPocoQuery<Database.ResellerQuery.Result>.GetEnumerator() + 0xb0 bytes

> OPS.exe!Database.CustomerByNameQuery.CustomerByNameQuery(Database.ResellerQuery.ParameterSource _parmsGetter = {Method = {Parameters Get_ResellerQueryParameters()}}) Line 513 + 0xa bytes C#

-- END STACK --

Your adapter code has been able to benefit us so far, but I really cannot continue unless I can find a way to query in a way that will let me add functionality to the resulting items. Any advice or insight will be helpful.

p.s. I have dug into the query translator a bit and I am wondering if perhaps the VisitParameter function which calls TranslateType is partially responsible. I wonder if the assignment would work if the parameter were not translated to an adapter when the parameter is for a member assignment. What do you think?

Thanks.

re: EF POCO Adapter updated (v1.03)

jkowalski — Sat, 22 Nov 2008 02:16:59 GMT

jlddodger:

I am aware of this problem. Unfortunately fixing that is much harder than it seems, but there may be worksarounds.

As part of the query translation EFPocoAdapter must translate queries in terms of POCO objects to use Adapter objects and generate a function that will convert the results back to POCO world. Translating POCO types to Adapter types is easy (there is 1-1 mapping between them and Adapter has all required properties of a POCO). Translating anonymous types is also doable, because C# compiler conveniently generates them using generic types where all property types are type arguments. Translating non-generic, non-entity types which have references to POCO entities is very hard as it would require a new type to be generated.

You may be able to work around the problem by switching to LINQ to objects before final projection (by calling AsEnumerable()):

var b = (from r in db.CustomerSet

where r.Name.Contains("AUTOMATED")

orderby r.Name select r)

.AsEnumerable()

.Select(c=> new Result() { Customer = c });

Let me know when it works for you.

Jarek

re: EF POCO Adapter updated (v1.03)

jlddodger — Sat, 22 Nov 2008 18:29:05 GMT

Alright, that sounds reasonable for an explanation. Just so that I am clear, calling AsEnumerable() will cross the Lazy Barrier and evaluate everything both on-the-client and eagerly.... is this correct?

Proceeding from the assumption that that is correct, I was wondering if perhaps I could change the basic layout of the receiving class to function with the Member-Initializer-Assignment instead of changing to client-side evaluation. For example, you had said that the reason anonymous types were possible is because the compiler instantiates a generic class where each parameter has a corresponding type to one of the generic class type parameters.

First off, really awesome insight into C# for me. Also, you said that it is easy to convert to an adapter type since it has all of the necessary parameters and the relationship to POCOs is one-to-one.

Can I directly take advantage of these facts in any way? Can I query for the adapter type? Or even declare my class as generic (hmm... can class type-parameters be used in member-initialization lists...) and construct it similar to an anonymous class type.

If I am wrong about the performance change going to client-side evaluation, then just let me know. I would love to find out that the easy answer is also the best.

re: EF POCO Adapter updated (v1.03)

jlddodger — Mon, 24 Nov 2008 17:09:09 GMT

Okay, just ignore the previous post. I have determined through testing that deferred loading is not affected by crossing to client evaluation. Also, because entire POCO objects are being requested (an entire Customer object), it makes no difference in network transfer amount whether the result object is constructed on the server- or client-side. Technically, I believe it may be more efficient to construct the result object on the client-side. Thank you for all your help.

re: EF POCO Adapter updated (v1.03)

jimitndiaye — Fri, 19 Dec 2008 22:27:31 GMT

Hi, I having a bit of problem. When trying to compile the generated PocoAdapters, I keep getting the following error: 'SomeClrNamespace.PocoAdapters.EntityAdapter' must be a non-abstract type with a public parameterless constructor in order to use it as parameter 'TAdapterType' in the generic type or method 'EFPocoAdapter.DataClasses.PocoAdapterBase<TPocoClass>.DetectChanges<TAdapterType,TValue>(TValue, System.Data.Objects.DataClasses.EntityReference<TAdapterType>, string)'

EntityAdapter and the Poco entity it targets, Entity are both abstract.

Does DetectChanges absolutely need the 'new' constraint? Cause if does then the generated adapter cannot handle the case wherein an abstract class is the target of an EntityReference relationship. For instance in your sample NorthWindEF model, if Territory had a NavigationProperty back to the Employee, the generated Adapter wouldn't work.

Can you recommend a work around?

Many Thanks,

Jimit Ndiaye

re: EF POCO Adapter updated (v1.03)

jimitndiaye — Tue, 23 Dec 2008 05:30:22 GMT

Is there any intention to support function imports in the generated Poco container?

EF POCO Adapter updated (v1.03): GetHashCode

wuwu1976 — Thu, 19 Mar 2009 15:27:08 GMT

Hello!

First of all, thanks for the great job done with the poco adapter...

I have found a problem for which I really hope you will help me...

So here it is:

I have following poco class: Group with long Id (primary key), string Name

My problem is, that when I get the group from 2 contexts, even though they are the same, the method groups.Contains(group) returns false, but it should return true.

HashSet<Group> groups = new HashSet<Group>();

using (MyEntities context1 = new MyEntities ()) {

Group group = context1.Groups.First(g => g.Id == 3);

groups.Add(group);

}

using (MyEntities context2 = new MyEntities ()) {

Group group = context2.Groups.First(g => g.Id == 3);

if (!groups.Contains(group)) {

groups.Add(group);

}

To make it work, I have override the GetHashCode method on the Group poco class:

public override int GetHashCode() {

//Group id is a primary key

return Id.GetHashCode();

}

So the code works now. But I get exceptions from the PocoAdapter when trying to detach the group, or when calling DetectChanges, SaveChanges, etc. The exception is "InvalidOperationException("Entity is already attached with another active context. Cannot reattach.")" and comes from your method GetAdapterObject(...). When it calls _adapterObjects.TryGetValue(entity, out value), the value returned is null.

As far as I can understand, you add the entities to the _adapterObjects dictionary and it adds them before they are filled with values...

Could you please help me out?

Thanks a lot in advance.

Kind regards

Marc Wuergler