Is there a way to get the datatype length from an entity framework table?
I am needing to create a table in the database if the EF and DB are not in sync, so grab the info from EF to create a script to create the table.
EF is DB agnostic. You can call the underlying DB directly to ask about the Metadata. You can also for types that allow (decimal, string etc) specify the length you would like in code first scenarios. EF first does a comparison to check code and DB match. You can request/trigger migration.
Actually you can't because EF maps all the DB fields to primitive data types (C#). So the best solution for this is to think logically for each data types. e.g map string datatype to nvarchar[max], true/false to bit or int....etc etc
Related
I have a database with two tables, one with a column numeric (19,4) and other with float.
I need to map (in Entity Framework 5 Code First) this two tables in entities that have the same type, such as decimal. Change the database is the best solution, although is out of question.
Anyone?
Entity Framework does not support such simple mappings (yet?) that require type conversions. It is on a feature request list but apparently not decided until now if simple type mappings will get better support in the future:
http://data.uservoice.com/forums/72025-entity-framework-feature-suggestions/suggestions/2639292-support-for-simple-type-mapping-or-mapped-type-con
A workaround is to use two properties in your model, one that is not mapped to a database column and one with a type matching the actual type in the database, and then to perform the type conversion between the two properties in their getters and setters. An example for this is here:
https://stackoverflow.com/a/14221906/270591
I have the below scenario. I am using EF 5 Code first, MVC 4 on VS 2010. I am using the Unit of Work and Repository pattern for my project.
I am not sure if this is possible or not. Kindly suggest.
I have a model class representing a database table. In the model class, I have a property that is decorated as [NotMapped]. I have a Stored Proc that returns data, similar to the model class. However, when I get the data in a List from the SP, it does not contain value for the [NotMapped] column (SP returns data for the [NotMapped] column though). This may be logically correct with respect to EF.
All I want to know is, do we have a way to get data populated for the [NotMapped] column. I want to achieve, CRUD using LINQ (excluding R - Read).
I would recommend to create a separate complex type for the stored procedure results. Otherwise sooner or later you will find yourself writing code to distinguish between entities coming from the DbSet or from the stored procedure. When the come from the stored procedure they can't be used in joins, for example. Or checks whether or not the unmapped property is set.
A very dirty approach could be to have two different contexts. With code first it is possible to have different contexts with different mappings to the same types, with and without the column ignored (if you use fluent mapping, not with data annotations). But that only succeeds if you tell EF not to check the database schema, so using migrations is ruled out as well. I would not do it!! For the same reason as I mentioned above. I would hate to have a type with a property that sometimes is and sometimes isn't set.
Trying to understand Entity Framework. My approach is database first. However I would like to define other entites in the model that is closer to my business objects. I guess I could write queries in the db and include them in the model. But I would also like to define entirely new entities in the model though they would be based on underlying tables in the db. How do I do that - does anyone know a tutorial?
Regards
Bjørn
db Oldtimer, EF Newbie
Database first means that you have existing database and you can either create model by updating from database or manually. You can use wizard to create initial model and modify it manually to define new entities but you must not use update from database any more or some of your changes will be deleted. Also your custom modifications must follow EF mapping rules (for example it is not directly possible to map multiple entities to the same table except some more advanced mapping scenarios like splitting and inheritance) and some of them (custom queries) must be done directly in EDMX source (XML) because designer doesn't support them - this requires more complex knowledge of EF mapping and it will be definitely hard for newbie.
You can check specification of that XML. For entities mapped to custom queries you will have to use DefiningQuery element in SSDL part of EDMX.
If we've been using an Entity Framework 4 model for some time, and we eventually want to switch the underlying database to a different vendor's product (say, from SQL Server to MySQL), is it simple to adjust the table and column mappings in the entity model without needing to update any of the entity class code?
We're trying to design code that is as database agnostic as possible, so I'd like to know in advance how much trouble we're in for if we ever switch our databases around. Ideally, we'd like to not have to touch our applications that use our entity classes. I can't seem to find any way in the entity designer or XML editor to adjust the underlying database column names without it giving me an error.
(I can, however, edit the entity's property names in the designer while leaving the database column names alone, but that's the opposite of what I need.)
Thanks!
EDMX is not database agnostic. SSDL part of EDMX is tightly coupled with database server (in case of MSSQL even with its version). You need separate SSDL for each supported database server.
I don't understand how changing column names relates to database agnostic model. Reverse is true! If you need your database to have different column names for different server products you need separate mapping for each of them!
Changing column names when using model first is possible only if you modify T4 template used for generating database creation SQL script. But every time you create that script designer will delete whole your storage description (SSDL) and mapping (MSL) and replace them with a new one.
The easiest way to have database agnostic code is using code first but even then you can have problems with some type and feature inconsistency among servers.
If you want database agnostic ORM you should probably check NHibernate.
How can I change the type of a Core Data entity column programmatically? For example, form String to Int 16. The entity can be assumed empty (no data row).
Firstly, it's not an SQL column, it's the attribute of an entity. Attributes have behaviors, columns in SQL do not.
In answer to your question, once a data model model has been used to write data to a persistent store file (sqlite store or other formats) it cannot altered programatically. If you change an attribute, you need to perform a version migration.
See: Core Data Model Versioning and Data Migration Programming Guide for details.
A little general advice: Core Data is not SQL. Entities are not tables. Objects are not rows. Attributes are not columns. Relationships are not joins. Core Data is an object graph management system that may or may not persist the object graph and may or may not use SQL far behind the scenes to do so. Trying to think of Core Data in SQL terms will cause you to completely misunderstand Core Data and result in much grief and wasted time.
You can manipulate the attributes (including) type of an entity in an NSManagedObjectModel until it is used to initialize a persistent store coordinator. So, create the NSManagedObjectModel, mutate the attribute (not a column) type, then setup the Core Data stack as usual.
Of course, if you already have any data persisted using the original model, you'll have to perform a schema migration to update the data to the new type.