Devart Forums

High!

After upgrading dotConnect for Oracle to version 7.2, while attempting to query entities with "GetTable<XXX>()" method, I started getting an InvalidOperationException: "The type 'XXX' is not mapped as a Table"

I created a simple console application to demonstrate it. What should I change to make this working?

using System;
using System.Linq;

namespace DevartLinq
{
[Devart.Data.Linq.Mapping.ProviderAttribute(typeof(Devart.Data.Oracle.Linq.Provider.OracleDataProvider))]
class MyContext : Devart.Data.Linq.DataContext
{
public MyContext(Devart.Data.Oracle.OracleConnection conn) : base(conn) { ObjectTrackingEnabled = false; }
}
[System.Data.Linq.Mapping.TableAttribute(Name = "ORGANIZATIONS")]
class Organization
{
[System.Data.Linq.Mapping.ColumnAttribute(Name = "NO", IsPrimaryKey = true)]
public long No { get; set; }
}
class Program
{
static void Main(string[] args)
{
using(var conn = new Devart.Data.Oracle.OracleConnection() { Server = "...", UserId = "...", Password = "..." })
{
conn.Open();
using(var cont = new MyContext(conn))
{
cont.GetTable<Organization>().Take(10).ToList().ForEach(o => Console.Write(o.No + ","));
}
conn.Close();
conn.Dispose();
}
Console.ReadKey();
}
}
}

Thanks!

DataContext is an abstract class, thus you should implement its descendant with the implemented property of type Table<Organization>. We have made some changes to your sample project and sent it to the e-mail address you have provided in your forum profile. Please check that the letter is not blocked by your mail filter.

Please note that since dotConnect for Oracle 7.0.6 the references to System.Data.Linq are removed, and LinqConnect uses only its own classes. So it is necessary to replace all occurrences of "System.Data.Linq." with "Devart.Data.Linq."

Please tell us about the results.

Thank you Mariia, your sample is working!

By the way, I tried to replace all System.Data.Linq classes by Devart ones earlier, but that didn't help.

As I see, the trick is that now my DataContext implementation must have public property or field of type "Table<MyEntity>" in order to "MyEntity" could be treated as a "true" entity.

Previous version I used didn't require this, and it's turned out rather unexpected for me

Glad to see that the sample project helped you to solve the problem.
In fact, this DataContext implementation should be the same in the previous versions when working with attribute mapping.

When creating the attribute mapping, LinqConnect runtime should have information about the classes for which to check the metadata attributes. The list of these classes is prepared based on the Table<TEntity> properties of the DataContext.
The mapping could be prepared without the Table<TEntity> properties, in case, e.g., when using the XML mapping, because all entity types are listed in the XML mapping file.

For more information please refer to:
http://www.devart.com/linqconnect/docs/ ... ntext.html
http://www.devart.com/linqconnect/docs/ ... asses.html

Nevertheless, the version we still use (Devart.Data.Linq.dll 3.0.5.0) DOES NOT need enumerating all entity types in DataContext descendant. Moreover, my implementation of it contains nothing but constructors and all is working

It seems that former release was able to process entities “on the fly”, while the new one requires all mapped classes been strictly defined before DataContext creation.

The main problem (not the only) is that many of our web pages define “local” classes, that inherit entities of a “main” set. Usually some extra properties were added, that were mapped to custom SQL query results with very cool DataContext Query<> method. We found this approach handy, since mapping attributes support inheritance. All these types could be hardly added to DataContext...

Also, the old behavior gave me capability to create entities at runtime using Reflection Emit and make some other tricks.

So, is there any chance that this limitation will be revoked, as significantly reducing flexibility

We have made a major refactoring of the LinqConnect engine. In particular, now metadata are obtained when the DataContext is created and they cannot be changed after that.
In earlier versions of LinqConnect it was possible to do when using attribute mapping.
We will consider the possibility of restoring this functionality. We will inform you about the results as soon as possible.
As a workaround, you could try using the XML or Fluent mapping. In this case, when table is defined in the XML/Fluent mapping file, it isn't necessarily to specify a property of type Table<TEntity> in the DataContext class.

For more information please refer to:
http://www.devart.com/linqconnect/docs/POCO.html
http://www.devart.com/linqconnect/docs/ ... pping.html

Using these mapping alternatives wouldn’t free me from the early listing of all entity types. There is no difference for me to enumerate them either as properties or in XML. My data access layer issues the DataContext instance and describes a base set of entity types. Other modules query them or their descendants. And DAL knows nothing about those locally defined types that were derived from the base ones. (BTW, only attribute mapping preserves mapping rules for members in inherited classes – please correct me if I’m wrong)

As a workaround to leave existing code in a working state I think of one sophisticated approach with overriding GetTable and Query methods. But I’d prefer to wait with upgrading, if a comeback of an old behavior is really possible

Using these mapping alternatives wouldn’t free me from the early listing of all entity types.

When using these alternatives, you can dynamically prepare XML mapping at runtime.

only attribute mapping preserves mapping rules for members in inherited classes – please correct me if I’m wrong

Could you please specify what exactly do you mean about it? Also, if possible please send us a sample that demonstrates this behaviour with inheritance.
In fact, all mapping kinds provide inheritance mapping.
Please refer to http://www.devart.com/linqconnect/docs/ ... pping.html

By “inheritance” I meant not an inheritance through mapping, but a simple C# inheritance. I hope the sample I’ve sent will make it clearer. Look at the class “InvestmentProjectWithName” – all members of the base class “InvestmentProject” were inherited with their mapping rules jointly. Any other mapping technique would force me to set mapping rules for all class members (including inherited) over again. (The “name” column does not exist in a database table – it’s added locally for custom query)

Please pay attention to the fact, that this sample uses the old dotConnect version assemblies (embedded to the project).

In addition that model allowed me to use a single DataContext instance per http request

Sorry for the delay.
Thank you for the sample project. We have investigated it, simplified it and sent back to you. Please test it and tell us if this helps.
In fact, if all the properties of your classes are always named exactly as the aliases in your queries (as it is seen by your example), you can actually provide no mapping to the context (see the modified sample).
If there are some scenarios in which you do need to create the mapping, could you please describe these situations in more details?

Well, the possibility to avoid a mapping at all is charming but can't help me

Actually, many properties ARE NOT named exactly as columns (you just removed a couple of such ones from my sample )

My own entity assembly generator removes some symbols ("$", "_") from column names. And it is absolutely ruled out to rename any DB schema elements

After all I decided to move to an XML mapping with some project transformations

Hello!

MariiaI wrote:...now metadata are obtained when the DataContext is created and they cannot be changed after that.
In earlier versions of LinqConnect it was possible to do when using attribute mapping.
We will consider the possibility of restoring this functionality.

Is there any news related to this functionality?
Thanks!

We are investigating the possibility of restoring this functionality, however we can't tell any timeframe at the moment. We will inform you about the results as soon as any are available.

MariiaI wrote:In earlier versions of LinqConnect it was possible to do when using attribute mapping. We will consider the possibility of restoring this functionality.

We have investigated the possibility to restore this functionality. Currently, there are no plans to implement it. The more suitable solution for such scenarios is using an XML Mapping or a Fluent Mapping approaches.

[quote="ruslan.net"]

Did you solved attribute mapping problem?
Can you explain the idea or post sources?

I shall be grateful for any information.