I am using Oracle and LightSpeed Orm and generating model from database.
It seems there is an issue while creating tables that are both plural and singular.
I am getting an error Error 2 Ambiguous moniker '/Ecom/ClaimType' encountered. It is used for both 'ClaimType' and 'ClaimType'.
In this specific instance it's tables CLAIM_TYPE and CLAIM_TYPES that get same (ClaimType) entity generated.
How do I generate two different entities for these?
This came back from lightspeed support:
You will need to split this into two separate model files. We require
entities to be uniquely named in a single model.
J.
(Which imho is ridiculous solution)
Related
Is it possible, in a code-first approach, to define two different context classes and use them simultaneously?
The database schema is already given and I cannot modify it (besides the creation of some new tables).
The problem I'm facing is that I'm getting "The model backing... has changed" error. It seems there's some kind of collision between the two contexts.
Note that each context includes a different set of tables, so sync problems aren't a concern.
Assuming you are using EF 6 or higher, this can be done either by the ContextKey-Property of DbMigrationsConfiguration (this will make the MigrationsHistory table multi tenant by ContextKey) or by setting HasDefaultSchema in OnModelCreating (this will enable multiple MigrationsHistory tables, one for each schema). For further instructions see the Documentation.
I am very new to entity framework and I am trying to do something like following scenario.
I am creating ASP.net web from application. That website needs to connect to two databases which the schemas are completely different.
I have no idea how the basic structure should be.
I though of have EF on class library. please guide me with instructions since I have less knowledge.
Since you are using two different databases, the only viable option is to create two separate conceptual models. Even if you would be able to merge two different databases into a single conceptual model, it would be a pain to maintain is the databases are of mentionable sizes.
The two models could reside within the same project, in seprate folders to get different namespaces.
E.g.:
Company.MyApp.DataModel
Company.MyApp.DataModel.Model1
Company.MyApp.DataModel.Model2
Then you could put a new layer on top of these two models which do all the heavy lifting, and could even make them look like one database if you want that, or merge data from entities in both models into a DTO or something similar.
Check out the Repository pattern.
If you think about it, when you create a EDM model with Visual Studio it ask you to give an existing database, and when finished creating the model, it generates an EF connection string, that internally address to the given underlying database connection string.
E.g: metadata=res:///EFTestModel.csdl|res:///EFTestModel.ssdl|res:///EFTestModel.msl;provider=System.Data.SqlClient;provider connection string="Data Source=.\;Initial Catalog=EFTest;Integrated Security=True;MultipleActiveResultSets=True"*
So each model matches only a database, only a connection string.
EF4 still does not support creating one conceptual model which works with N storage models. At least this is not supported with any built-in provider. Perhaps in the future this could be done through a new provider that combines the support of many storages (from the same providers or different).
I havent done enough research on it, but perhaps Windows Server AppFabric (Codename Velocity) could be the bridge to go through this gap.
Note: I have tried even editing manually the xml for the EDM (edmx) to insert a second element inside the tag but it does not match the EDM XML Schema so VS warns about it: Error 10021: Duplicated Schema element encountered.
You are going to use model first approach as the database already exists.
You will need to create two edmx for the two database.
You can create one model project which you can have connection strings for both the edmx in the app.config file and then create your edmx.
I'd like to know how to (if possible) associate tables from different databases using entity framework. I have one edmx for my "xyz" database and another for my "abc" I need to associate them using EF. I know how to fix this using FKs, but that's not what I want, I'd like to be able to do that using the visual editor, not adding, by hand, a FK to my DB.
Here's a pratical example of what I'd like to accomplish:
Table User - database: abc
Table Message - database: xyz
I'd like to associate User to Message and vice-versa.
Could anyone help me?
Thanks!
You can query them together with Linq-to-Objects, but not with L2S or L2E.
A context is wrapped around 1 Db-connection, you cannot track/update entites from multiple db's.
A possible workaround is to 'link' to one of the Db's from the other. MS-SQL can do this. To the EF it would appear 1 database.
There is no way to achieve this using the edmx design surface in EF.
You could encapsulate this association within your domain model and provide a distributed transaction across the two EF Contexts. We've implemented the latter with an EF Context "container" class that given an internal collection of contexts uses a TransactionScope when it contains more than one context (this relies on the IUnitOfWork abstraction to work effectively).
So I have multiple copies of the same database. Some of the tables are slightly different, but the ones I'm generating EF entities against are all identical. Does EF4 support making database calls against different databases just by swapping out the connection string or is it coupled somehow to the database it was generated against?
You shouldn't have any pain by simply swapping the connectionstring assuming the databases are really identical. See it this way, the .edmx consists out of three parts:
Entity definition
Database definition and
Mapping between these two.
Whether you use the entity model against db1 or db2 doesn't matter at all as long as one of those db's was used to generate the entity model and "db1=db2". The Sql that EF generates under the hood to communicate with the database is based entirely on the .edmx. So as long as your databases are identical expect no problems, they can be "reached" based upn the same .edmx! Try it yourself!
If you are really interested in EF and planning to use it, this (Programming Entity Framework by Julie Lerman) is a must read
What do the people mean when talking of the plurality naming "problem" in context of Entity Framework?
From http://www.cnblogs.com/zjz008/archive/2010/06/03/1750442.html (re: Entity Framework 4.0 Features)...
Plurality Naming
One of the big complaints in the first
version of the Entity Framework was
how naming conventions were applied to
EDM objects such as entities and
navigation properties when using the
model wizards.
The first version of
the Entity Framework gave the Entity
Name and the Entity Set Name the same
name. There was no attempt to
singularize or pluralize names when
generating a model from a database.
The problem is that this caused some
confusion when referencing the
database table or EntityType in code.
For example, if your database has a
table called Employees, then you will
also get an EntityType called
Employees as well. This causes
confusion about whether you are
referencing the table or the
EntityType, such as in the code
fragment below.
Customers customer = new Customers();
Luckily, this issue
has been addressed. The model wizards,
both the Entity Data Model and Update
Model Wizards, now provide the option
of using singular or plural forms of
names for entities, entity sets, and
navigation properties.
The goal of
this change was to make the
application code much easier to read
and avoid a lot of the confusion
between object names.
It revolves around the fact that database objects named in certain ways will lead to either incorrect pluralization or singularization. A good example of this is illustrated by this Microsoft Connect issue.
In this example, database objects end in "Status" are incorrectly singularized as "Statu", instead of being treated as a singularization that would be pluralized as "Statuses".
It is annoying, but I wouldn't consider it to be widespread enough to deter a person from using EF.