Problems with EF Code Only support with DevArt

ghostknight · Post by **ghostknight** » Thu 08 Apr 2010 07:10

Devart declared that it supports latest versions of EF... But seems it doesn't work with EF Code Only at all with Oracle. Is this a Devart's bug or EF one? I've described the problem in details here on MSDN Social:
http://social.msdn.microsoft.com/Forums ... d55f890d61

Naming schema as "dbo" seems to be EF bug. But enclosing every identifier in quotes... AFAIK EF generates queries using underlying ADO.NET Provider (dotConnect for Oracle in the case). So, who encloses all identifiers in quotes?

Could anybody help on this?

Thanks in advance.

AndreyR · Post by **AndreyR** » Thu 08 Apr 2010 12:20

Both prefix and quotation problems seem to be generated by the EF mapping engine.
We only perform the translation in this case.

ghostknight · Post by **ghostknight** » Thu 08 Apr 2010 12:33

AndreyR wrote:Both prefix and quotation problems seem to be generated by the EF mapping engine.
We only perform the translation in this case.

If this problems will remain in release - do you plan to develop any kind of fix in your Provider? For example - removing that previx and quotes? Or users will have to write their own query interceptors?

AndreyR · Post by **AndreyR** » Thu 08 Apr 2010 12:40

We will investigate the possibility to work around this behaviour in case the fix is not available in the EF v4 release.

ghostknight · Post by **ghostknight** » Thu 15 Apr 2010 08:01

They promise to fix "dbo" issue. But the quotes issue seems to be at Devart's side - because the provider handles CommandGeneration. Unfortunately libraries are obfuscated, so it was hard to find the specific place where attribute names are generated.

The call sequence is like that:
System.Data.Mapping.Update.Internal.DynamicUpdateCommand.CreateCommand
-> UpdateTranslator.CreateCommand
-> DbProviderServices.CreateCommand
-> CreateCommandDefinition
-> CreateDbCommandDefinition(DbProviderManifest providerManifest, DbCommandTree commandTree); // here we go into Devart.Data.Oracle.Entity.OracleEntityProviderServices.
-> DbCommand prototype = this.a(providerManifest, commandTree);
-> return new e().a(A_1, null, A_0);
-> else if (A_0 is DbInsertCommandTree)

b.a(tree2, command, A_2);
->A_0.Target.Expression.Accept(visitor); //here we add a table name
this results into call to
Devart.Data.Oracle.Entity.b.a.a(DbScanExpression A_0)
{
base.a.Append(e.a().a(A_0.Target));
}
-> Devart.Common.Entity.j.a(EntitySetBase A_0)
here the Schema name is retrieved
if (A_0.MetadataProperties.TryGetValue("Schema", false, out property) && (property.Value != null))
{
str2 = property.Value as string;
}
if (!string.IsNullOrEmpty(str2))
{
builder.Append(this.b(str2));
builder.Append(".");
}

and here is the root of evil:
builder.Append(this.b(str2));
call to abstract method. Implementation is at
Devart.Data.Oracle.Entity.e.b(string A_0)
{
return b.d(A_0);
}

that is
public static string d(string A_0)
{
if (f(A_0))
{
return ("\"" + A_0 + "\"");
}
return A_0;
}

so Schema name is enclosed in quotes be Devart dotConnect!!

returning to the method where we started with Schema name retireval. Later we append table name:
if (A_0.MetadataProperties.TryGetValue("Table", false, out property) && (property.Value != null))
{
str3 = property.Value as string;
}
if (!string.IsNullOrEmpty(str3))
{
builder.Append(this.b(str3));
}

so it is processed through the same code and enclosed in quotes.

The same applies to all propertyNames as in

public override void a(DbPropertyExpression A_0)
{
base.a.Append(b.d(A_0.Property.Name));
}

there is a direct call to
Devart.Data.Oracle.b.d(string A_0) method that encloses everything in quotes.

So, enclosing identifiers in quotes is done definitely on Devarts side and is a serious bug preventing from using Devart dotConnect with Oracle.

Sad.

AndreyR · Post by **AndreyR** » Fri 16 Apr 2010 11:46

We have replied you here:
http://www.devart.com/forums/viewtopic.php?t=17570