My existing table contains nearly 50 columns, most of them have the 'default' constraint.
I have created the model based on this database table. All seemed ok, until i tried to insert a new row. I've got a sql server error stating that some column cannot be null. It appears that creating a model from the database did not preserve the default constraints.
I edited the model manually adding all the defaults and after that inserting didn't fail.
So my question is, how do i create a model that automatically picks up default constraints associated to the columns?
Using mvc4, visual studio 2010, sql server 2008 r2.
Google search didnt make sense as all the people seemed to be talking about something different than what i need.
Pretty sure my answer from Possible to default DateTime field to GETDATE() with Entity Framework Migrations? will work for you too. By using a modified MigrationCodeGenerator class and iterating through the operations list you can update the columns and add DefaultValueSql values based on whatever rules you need.
Well, you have a number of options. You could set the default values in the Model's default constructor. I think this is the better solution.
If you must have the default constraints in your database you could do set defaultValueSql in your data migrations like this:
AddColumn("ExistingTable", "NewColumn",c => c.Int(nullable: false, defaultValueSql: "0"));
Related
How can one change the default ApplicationUserManager, so that it won't try to add to "PhoneNumber", "PhoneNumberConfirmed" and "TwoFactorEnabled" columns in the db? I do not need those columns, so I have them removed as well as all the views/methods that are connected with them. And although I can't find anything else in the project code, ApplicationUserManager still tries to add those columns.
Unfortunately you cannot remove those columns from the database. The default implementation of IdentityUser has those columns in it so you can't remove them (at least not without getting the source code for Identity and removing them yourself.
I am using grails GORM for database mapping and oracle as database which is already populated with values.My question is can I define a new constraint like Foreign key in the domain class even if its not defined in the underlying table in my legacy db?The grails app is still going to accept the constraints right?The constraints dont have to exactly match those of database right?
you can define attributes of a class, which are not saved in the db and due to this don't need a representation in the db these attributes are defined as follows:
class Person {
String name
static transients = ['name']
}
see information about transients. In 2.x transients are not auto-bound as listed in the docs here, so you have to do a bindable: true explicitly.
Yes, the constraints you define in your domain class will be respected regardless of what you have in your database. The only time the 2 really relate is if you are letting Hibernate generate DDL for you (which most folks do not do for their production environment) in which case there are certain constraints which affect the DDL that is generated. Since you already have a database you almost certainly have that turned off.
EDIT:
An example of a constraint which affects DDL is the size constraint. If you constrain a String field with something like size: 5..15, by default the DDL that is generated will create a column that is 15 characters wide. If you are not allowing the app to generate DDL that constraint is still applied at validation time and if the property has more than 15 characters or fewer than 5, validation will fail. Once validation passes and the data is sent to the database, the framework assumes everything will be ok there. If it isn't, then corresponding exceptions may be thrown. For example, if the String has 12 characters it will pass validation in the app and will be sent to the database. If the database column is only 8 characters wide, you are going to get a SQLException. I hope that makes sense.
I can't find any info about this in the documentation, so I will ask here. How does breeze handle database column defaults? I have required columns in my database, but there are also default static values supplied for these in the database column definitions. Normally, I can insert null into these columns, and the new records will get the default. However, breeze doesn't seem to be aware of database column defaults, and the entities that have null in these columns fail validation on saving.
Thanks,
Mathias
Try editing the edmx xml by adding StoreGeneratedPattern = "Computed" attribute to the column with default value in the DB.
Edit:
Actually, before doing editing the xml, try setting the StoreGeneratedPattern property to Computed in the model editor itself.
Update:
This was fixed in Breeze 1.4.6 ( or later), available now.
Original Post:
There is currently in a bug in Breeze that should be fixed in the next release, out in about week. When this fix gets in then breeze will honor any defaultValues it finds in the EntityFramework data model.
One problem though is while it is easy to get 'defaultValues' into a Model First Entity Framework model via the properties editor, it's actually difficult to get it into a Code First EF model, unless you use fluent configuration. Unfortunately, EF ignores the [DefaultValue] attribute when constructing Code First model metadata.
One workaround that you can use now is to poke the 'defaultValue' directly onto any dataProperty. Something like:
var customerType = myEntityManager.metadataStore.getEntityType("Customer");
var fooProperty = customerType.getProperty("foo");
fooProperty.defaultValue = 123;
I want to override the default nvarchar(4000) for one of my string columns to a text data type in SQL Express. I use this code.
modelBuilder.Entity<Accommodation>()
.Property(p => p.Information)
.HasColumnType("text");
But the column type remains as nvarchar?
I also asked here http://social.msdn.microsoft.com/Forums/en/adonetefx/thread/a1d84ea9-2f8e-42f0-bb83-ac9f68805d6d?prof=required
Ahh I just figured it out, adding the fluent mapping was not sufficient to force the table to dropAndCreate itself again even though I had DropCreateDatabaseIfModelChanges set.
I had to force it to update the table manually.
I like using LINQ to SQL. The only problem is that I don't like the default way of updating tables.
Let's say I have the following table with the following columns:
ID (primary key), value1, value2, value3, value4, value5
When I need to update something I call
UPDATE ... WHERE ID=#id
LINQ to SQL calls
UPDATE ... WHERE ID=#id and value1=#value1 and value2=#value2 and value3=#value3 and value4=#value4 and value5=#value5
I can override this behavior by adding
UpdateCheck=UpdateCheck.Never
to every column, but with every update of the DataContext class with the GUI, this will be erased. Is there any way to tell LINQ to use this way of updating data?
I'm confused by this statement:
but with every update of the DataContext class with the GUI, this will be erased. Is there any way to tell LINQ to use this way of updating data?
By "the GUI", do you mean the Linq to SQL designer? Because the property sheet for each member has an "Update Check" property that you can set to "Never". If you are manually editing the .designer.cs file, don't do that, instead change the Update Check setting in the actual designer.
Designer Screen http://img29.imageshack.us/img29/7912/updatecheckdesigner.png
Please note: The "default way" of updating used by Linq to SQL is called optimistic concurrency, and is a way of preventing conflicting updates from multiple users. If you turn this off by using the method above, you have to be prepared to deal with the fact that if two users have the same record open at the same time, the second user's changes will overwrite the first user's changes without any warning or confirmation. Be sure that this is the behaviour you really want.
Unfortunately, no, there's not. You have to edit the DBML manually after it is generated (or updated) - which is a pain (or use the Designer as already mentioned in the other answer).
When I last used L2S on a project, I wrote a quick utility which ran post-generation and fixed it up, but it's an unnecessary pain which (c)shouldn't be required IMHO.
Ran into this one myself. The trick is to change the way one generates the DBML--such as using l2st4. Then you can set that pesky UpdateCheck property to always be never by modifying the template.
That is how Linq works. Why don't you like this update behavior?
Read about optimistic concurrency
http://msdn.microsoft.com/en-us/library/bb399373.aspx