I need to dynamically access some SQL tables hopefully using the Entity Framework. Here's some pseudo code:
var Account = DB.Accounts.SingleOrDefault(x => x.ID == 12345);
which will return me an Account object and this contains some fields called "PREFIX", "CAMPAIGN ID" and further information about the accounts are stored in separate SQL tables with the naming convention of PREFIX_CAMPAIGNID_MAIN.
The tables all have the same fields so I was thinking of creating a new Entity that isn't mapped anywhere and then dynamically loading it, like so:
var STA01_MAIN = new MyAccount(); // my "un-mapped" entity
DB.LoadTable('STA01_MAIN').LoadInto(STA01_MAIN);
I can now get anything about the STA01_MAIN account: STA01_MAIN.AccountId.
So my question is: how do I access these tables using the Entity Framework?
I don't think EF has a LoadTable and LoadInto method, but ObjectOntext.ExecuteStoreQuery might be what you're looking for:
http://msdn.microsoft.com/en-us/library/dd487208.aspx
This should let you execute an arbitrary query against your database, and then map the results to an arbitrary type that you specify (even if it's not otherwise mapped in EF).
It goes without saying that you would be responsible for putting together a query that supplied the necessary columns for mapping into the destination type, and also adjusting said query when this type changes.
Here's some further discussion concerning its usage
http://social.msdn.microsoft.com/Forums/en-US/adonetefx/thread/44cf5582-63f8-4f81-8029-7b43469c028d/
Have you considered mapping all of these tables (with the identical columns) into an inheritance relationship in EF, and then querying them as
db.BaseTypes.OfType<SpecificType>().Where(/*.....*/);
Related
I have more than 50 data tables that have nearly identical structures. Some of the tables have additional columns. I'm developing an application to help me monitor and track changes to the data contained in these tables and only need to be able to read the data contained in them. I want to create an entity framework model that will work with all of the tables and give me access to all columns that exist.
As long as the model contains the subset of columns that exist is all of the tables my model works and I can dynamically switch between the tables with the same model. However I need accesses to the additional columns when they exist. When my model contains a column that doesn't exist in the table that I switch to I get an exception for an invalid column. Is there a way to have my model be the set of all columns and if the column doesn't exist in the context of a particular table handle it in a way that I still have access to the columns that exist? I know that using strait SQL I can do this quite easily but I'm curious is there is a way to do this with entity framework. Essentially I am looking for the equivalent of querying sys.columns to determine the structure of the table and then interact with the table based on knowing what columns exist from the sys.columns query.
Sample of issue:
The 50+ tables hold data from different counties. Some of there counties have included additional data, for instance a url link to an image or file. Thus I have an column that is a varchar that contains this link. Many of the counties don't supply this type of attribute and it isn't apart of the table in other counties. But there are 100 other reported attributes that are common between all tables. I realize a solution to this issue is to have all tables contain all possible columns. However in practice this has been hard to achieve due to frequent changes to provide more to our clients in certain counties.
From the EF prospective I do not know a solution but you can try something with an extension method like below:
public static DbRawSqlQuery<YourBaseModel> GetDataFromTable(this ApplicationDbContext context, string tableName)
{
return context.Database.SqlQuery<YourBaseModel>("select * from " + tableName);
}
I think this will map only columns that exists in table with properties in your model.
This is not tested by the way but it can give you an idea of what I mean.
Entity Framework supports generating Table per Concrete type mapping, this lets you have a base class that contains all the shared columns, and derived classes for each specific table
https://weblogs.asp.net/manavi/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-3-table-per-concrete-type-tpc-and-choosing-strategy-guidelines
I have my framework setup with code first with a BaseEntity type that simply contains Id and a Name properties (all my db tables have at least these two fields). The problem is that the db was written before we implemented EF so many of the columnnames in the db do not match this nice Id/Name convention (for example there might be CustomerId and CustomerName etc). Now as far basic CRUD operations go this works fine because I simply do this in my mappings:
this.HasKey(t => t.Id).Property(t => t.Id).HasColumnName("CustomerId");
and it correctly maps from one to another and all is good
However, we also have some complex database logic that can only be encapsulated in stored procedures so in my ObjectContext I have a generic method for invoking sprocs that returns IList and allows you to pass in the name of the proc to invoke and any params it requires, it then goes to the underlying Database object on the ObjectContext to make the call. This works great for classes where the property names in the poco match those in the db, but if they do not, it ignores any mapping I have setup for that object (see above) and I get an error like this:
The data reader is incompatible with the specified 'SomeNamespace.Customer'.
A member of the type, 'Id', does not have a corresponding column in the data
reader with the same name.
Is there any clean way to work around this or to properly instruct it to map it correctly on the underlying datareader?
thanks
I have an abstract parent entity with 6 inherited child entities, using TPH in EF4.
Is there a simple way to get the value of the dicriminator column, bearing in mind that although at the moment it is the same as the Type.Name, this does not have to be the case.
In my case, I am importing data from many sources into a single table for processing - so the Disc is very useful so I only have one table, which I can expand to take in many sources.
I'd like to be able to simply loop through the collection and get the value of the discriminator - I would have thought that should be possible/sensible?
Discriminator column is represented by the type of the entity so you can use:
foreach (var entity in context.MyTPHEntities.OfType<SubtypeA>())
{
...
}
To get all SubtypeA instances in your TPH hierarchy or
foreach (var entity in context.MyTPHEntities)
{
if (entity is SubtypeA)
{
...
}
...
}
To work with all entities and their types = discriminator values.
Discriminator cannot be mapped as a property so you cannot get its value directly without diving deep into MetadataWorkspace and traversing mapping at runtime - that would require some time spend in debugger to find a way for retrieving the mapped value. Still you will not be able to use discriminator column in LINQ queries or for inserting new entity via EF. It can be only useful for native SQL access.
If you want to loop trough your table and just read the discriminator column you could use an EntityReader to do this.
Check out the following information: How to: Execute a query
I have a design question related to Entity Framework entities.
I have created the following entity:
public class SomeEntity {
// full review details here
}
This entity has as an example 30 columns. When I need to create a new entity this works great. I have all of the required fields in order to insert into the database.
I have a few places in my app where I need to display some tabular data with some of the fields from SomeEntity, but I don't need all 30 columns, maybe only 2 or 3 columns.
Do I create an entirely new entity that has only the fields I need (which maps to the same table as SomeEntity, but only retrieves the column I want?)
Or does it make more sense to create a domain class (like PartialEntity) and write a query like this:
var partialObjects = from e in db.SomeEntities
select new PartialEntity { Column1 = e.Column1, Column2 = e.Column2 };
I am not sure what the appropriate way to do this type of thing. Is it a bad idea to have two entities that map to the same table/columns? I would never actually need the ability to create a PartialEntity and save it to the database, because it wouldn't have all of the fields that are required.
Your first approach is not possible. EF doesn't support multiple entities mapped to the same table (except some special cases like TPH inheritance or table splitting).
The second case is common scenario. You will create view model for your UI and either project your entity to view model directly in query (it will pass from DB only columns you project) or you will query whole entity and make conversion to view model in your application code (for example by AutoMapper as #Fernando mentioned).
If you are using EDMX file for mapping (I guess you don't because you mentioned ef-code-first) you can use third approach which takes part from both mentioned approaches. That approach defines QueryView - it is EF based view on the mapped entity which behaves as a new read only entity. Generally it is reusable projection stored directly in mapping.
What you proposed as a first solution is the "View model paradigm", where you create a class for the sole purpose of being the model of a view to retrieve data and then map it to the model class. You can use AutoMapper to map the values. Here's an article on how to apply this.
You could create a generic property filter method that takes in an object instance, and you pass in a string array of column names, and this method would return a dynamic object with only the columns you want.
I think it would add unnecessary complexity to your model to add a second entity based on the same data structure. I honestly don't see the problem in having a single entity for updating\editing\viewing. If you insist on separating the access to SomeEntity, you could have a database view: i.e. SomeEntityView, and create a separate entity based on that.
I am trying to use EF with an existing DB. I brought in a Client table into my data model and let EF create a Client entity. I have a sproc, GetClientSearch, that only returns 5 out of the 15 columns from the Client table becuase that is all that is needed for that call.
Here's what I've done so far:
Added the sproc to Function Imports and set the proc to map to the Client entity.
When I execute the proc through the Context, I get "The data reader is incompatible with the specified 'GAINABSModel.Client'. A member of the type, 'MiddleInitial', does not have a corresponding column in the data reader with the same name." exception. (MiddleInitial is not one of the columns returned in the proc)
I know that I can create a new entity that maps to the proc, but I don't want to do that for every proc I have to import into my model.
Given that the DB is currently in use in production, changing stored procs to map to my current entities may not be an option.
Currently using EF 4 and VS 2010.
So, is there a way to map the results of the sproc to the Client entity, even though the columns returned are not 1:1 with the properties of the EF entity?
Yep, one of my many pain points in EF.
If you can't modify the SP's, your best bet might be to create "wrapper" SP's on top of the existing SP's.
In other words, EF-serving SP's that call into the existing ones, and return NULL for the columns you don't need, but are required for the entity.
Of course the better option would be to create the entities properly.
Another option is to use ObjectContext.Translate<T>, which basically performs a L-R between the SPROC results and the entity you supply.
If the result set doesn't contain the field, then the property on the object will be null.
Which is probably what you want.
Am running into the same Issues. Suppose i have UserEntity created out of the User Table and have 3 procedures.
AuthenticateUser - returns 4 columns from the user table after authentication
RetriveUser - Returns 10 columns from the user table
GetUserName - return UserID and UserName only for dropdown purpose.
If we create different entities for each of the different SP. It would result in bad design because of duplication.
I have no other way of using same entity for all these SP's.
Overall, i don't recommend entity framework atleast for legacy applications in production.(where you can not update your Sp's also.)