Working in an ongoing ASP.NET Core application, recently updated to v7.0, utilizing SQL Server database. We scaffold from the existing database (database-first model).
On my first time to scaffold and add some additional tables since moving to .NET 7.0, I'm running into issues... because most of our BIT columns in the database have a default constraint, and as stated here https://github.com/dotnet/efcore/issues/10840 :
If a BIT column has a DEFAULT constraint, we make the property nullable regardless of whether it has a NOT NULL constraint. This allow you to use the default value in EF.
So.... after scaffolding I'm getting hundreds of errors for columns that are defined as BIT NOT NULL but the model shows as bool? (nullable) because of this change.
Is there a command option in scaffolding to override this behavior, so that our default constraint in the database can remain, but our columns are still defined as NOT NULL within the application? I've seen mention of changing the .HasDefaultValueSql() setting, but that only applies to code-first implementations, not database-first.
I've seen mention of changing the .HasDefaultValueSql() setting, but that only applies to code-first implementations, not database-first.
There is no real difference between code-first and database-first any more. It's all technically code-first, even if the code-first configuration is generated from the database metadata. So any solution that works in code-first can be adapted to your scenario.
If you don't like how the entities are generated you can now customize the reverse-engineering templates.
Related
Background
The application in question is a WebCenter 11g in-house development project using ADF Business Components, JSF 2.0, and Facelets, and is being developed using JDeveloper 11g Release 2, version 11.1.2.4.0. The model project contains an Entity Object with many values for reviewing business projects. The view controller project contains a single page within a bounded task flow, which houses an input form referencing these values for creating and editing reviews. ADF Security features are enabled across the application. In the context of these reviews, intended functionality indicates one class of users can only edit certain "S.E." values, while other users can edit all values and create new reviews. To facilitate this, Entity Attribute-level security has been implemented for the reviews.
The Issue
The review form renders correctly, with the exception of a small, random selection of the values' input elements (eight out of 40) that render as read-only/disabled only when editing an existing record, but have no issue when creating a new record. When testing using the AppModule testing functionality, the same results are observed: the same eight values can be edited by the test user only for new records, while all other values are editable for new and existing records.
Specifics
The View Object and Entity Object Attributes for these values are all configured with the Updatable property set to Always. These values include some of the aforementioned "S.E." values, but not all of them - nor are all of the values at issue included within the "S.E." value group. The test user is set as an administrator for the application, an Application Role to which all Resource Entitlements are granted.
Failed Resolutions
I've attempted changing the View Object and Entity Object Attributes' Updatable attributes to While New and Never, then switching them back to Always - confirming that the changes were made in the XML file with each switch. I've checked and rechecked the ADF Security configuration several times, and confirmed the security for each of those values is identical to that of the other values in the same form/Entity for which the issue does not occur. I've cleaned the application and rebuilt the projects (model and vc) individually before deploying to a freshly launched Integrated WebLogic Server; I've closed and relaunched JDeveloper before rebuilding and redeploying; I've even restarted the computer, as sometimes the nature of my enterprise causes odd issues with JDeveloper that are only resolved by a log out or restart of the entire system. I've also confirmed that the issue occurs on my coworker's machine.
Ground Rules
Due to the nature of my environment, I cannot divulge explicit details of the application, and the following suggestions are unacceptable.
Upgrading JDeveloper
Upgrading Java
Upgrading WebLogic/WebCenter
Upgrading ADF, JSF, or any other library
As it turns out, this issue was caused by an ADF Security/JDeveloper SNAFU. The Entity Attributes in question were renamed (refactored) at some point, and for some reason this change propagated to everything ... except the Attributes' permission configuration. The Attributes and all other references to them held the new names, but their Permission elements in the Entity XML file still held the old names. This was not apparent until reviewing the XML directly, as the JDeveloper UI for ADFBC Entities does not reflect the warning state shown in the XML editor. The solution, then, was to either disable and re-enable Attribute-level security for those Attributes or to manually adjust the Permission elements' parameters within the XML.
I am using an EF Reverse Engineer Code First project. Specifically, I used the Entity Model, code first from database method that allows one to select only a subset of the database tables for a particular MVC project.
The primary key column/member for one of my table models is present in the table model, but when I auto-generated the views from the controller the primary key column/member is missing, except from the Create View.
Is this standard behavior for the new version 6 -- Visual Studio Entity Framework Tools or did I do something wrong?
If it is standard behavior, is there way to modify a setting so that the primary key column is present in the views?
I'm looking for an easy solution to generate automatically the validation rules in the model from the database constraints in Cakephp because I don't want to make that all by hand with cake bake. So e.g. if there is a NOT NULL constraint for a field in the database it should create a "not empty" validation rule for the field.
So is there a tool that can do this sort of thing?
CakePHP does not support this by default, but I like the idea.
But you could implement that by overloading AppModel::__construct(), adding code into the AppModel::beforeValidate() callback, load the schema by using CakeSchema for the table the model is using and loop over the schema it returns and build rules on the fly and set them to $this->validate.
If you don't want a specific model do it you could add another property like boolean autoValidationRules. Also check if notEmpty is not already set and don't overwrite it automatically or merge it, depends on your needs.
Edit: Try this behavior, I just hacked it together because I like the idea. Going to add an unit test later tonight.
https://github.com/burzum/BzUtils/blob/develop/Model/Behavior/AutoValidateBehavior.php
Indeed there is no built-in feature in CakePHP for this.
Otherwise if you don't want to use the console, you can use an online tool that allows you to design your applications : Models, relations and validations rules, and then automatically generate a SQL file with the right constraints on columns, your Models with the corresponding validation rules for fields, Controllers and Views : Online Cake Bake.
You do not get to do exactly what you want, but at least you get to design your database's constraints and your validation rules at the same time which saves a lot of time.
Some days I love my dba's, and then there is today...
In a Grails app, we use the database-migration plugin (based on Liquibase) to handle migrations etc.
All works lovely.
I have been informed that there is a set of db administrative meta data that we must support on every table. This information has zero use to the app.
Now, I can easily update my models to accommodate this. But that answer is ugly.
The problem is now at each migration, Liquibase/database-migration plugin, complains about the schema and the model being out of sync.
Is there anyway to tell Liquibase (or GORM) that columns x,y,z are to be ignored?
What I am trying to avoid is changesets like this:
changeSet(author: "cwright (generated)", id: "1333733941347-5") {
dropColumn(columnName: "BUILD_MONTH", tableName: "ASSIGNMENT") }
Which tries to bring the schema back in line with the model. Being able to annotate those columns as not applying to the model would be a good thing.
Sadly, you're probably better off defining your own mapping block and taking control of the Data Mapper (what Hibernate essentially is) yourself at this point. If you need to take control of the way the database-integration plugin handles migrations, you might wanna look at the source or raise an issue on the JIRA. Naively, mapping your columns explicitly in the domain model should allow you to bypass unnecessary columns from the DB.
I'm now using Entity Framework 4.3 DbContext to generate database entities, my question is when i change the database, how can i ensure the auto-generated code are updated? where does EF to store database rules, like allow null from No to Yes. When i use the Update Model From Database function from .EDMX file, it seems does not update the allow null rules of the table. How can i solve the database changes problem. Where is the code behind to store all these rules.
The error message:
Validation failed for one or more entities. See 'EntityValidationErrors' property for more details.
But when i delete all EF auto-generated file and re-generate it again, it seems the rules are updated. But i thought it is not a good way to solve the problem during development period.
When i use the Update Model From Database function from .EDMX file, it
seems does not update the allow null rules of the table.
That is correct behavior. EDMX file has three parts:
database definition (only visible in model browser)
class definition (that is what you see in designer)
mapping between definitions (that is what you see in mapping details)
When you use Update from database the designer will completely replace database definition and adds new tables or columns to mapping and class definitions. It will never try to remove or change anything. The reason for this is that class definition is customizable. If you make your changes you don't want designer to touch them. Update from database has only actual state - it doesn't know which changes were made by you and which changes are caused by modifying the database so it simply use the better way - don't modify anything and let you to correct inconsistencies.