-
-
Notifications
You must be signed in to change notification settings - Fork 292
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Virtual property and collection named badly when field name ends in f.ex. GUID #1205
Comments
There is no simple fix for this, maybe you can try the Use Database names option |
I tried the use database names option to no avail. For the naming of the virtual properites, the problem "feels" like some code that looks for something in a foreign key / relation name / key that ends in "ID" and then just trims off the last 2 chars instead of 4 characters. I'm just not clear on how/why the logic is applying GU (or GUs) to virtual properties that are created. I haven't studied how EF 6 (framework) generates names when creating the EDMX and classes from database but it seems to have it nailed down very well. If there is any possiblity of adjusting the naming logic to match EF6 or at the very least resolving the "GU" problem it would be most helpful. |
The Id Thing is in EF Core, and I cannot properly override it. Disable pluralization. |
Thanks for the additional details. Pluralization on or off makes no difference with respect to the ID problem. The ID problem (IE: virtual methods leave "GU" in names of virtual properties) is apparently an issue with EF Core if I undertand correctly that the "reverse engineer" feature is either partially or fully a feature in EF core. I'm new to EF Core and this would seem to be a bug in my view. Is it appropriate for me to follow up somewhere with the folks that manage the EF Core project regarding the "GUID" name issue and virtual methods? If so maybe you can point to the correct place for raising that issue... |
You should report in the EF Core repo, this look like a potential duplicate: dotnet/efcore#14278 |
Looks like GetDependentEndCandidateNavigationPropertyName need to be overridden in this case |
@TimesliceTechnologies What is your proposed fix, looks like I can implement something. Is it: Leave the name alone, even if it ends with "id" (case insenstive) Or is it: Leave the name alone unless it ends with "Id" (case sensitive) |
Sorry for the delayed reply. In lieu of that, then strip off GUID the same as it strips of "id" or "ID" or "Id" would be an improvement that in my example at least would be an improvement. I realize this isn't your design and is part of the currently EF6 Core code that you rely on. Fundamentally, the reverse engineer should result in exactly the same model that EF6 Framework would create using EF6's "create from database" feature. Otherwise migration is a huge nightmare for anyone trying to migrate an application of any significant size from EF6 to EF6 Core. I have not examined the EF6 core code you referenced in any depth, but there seems to be an erroneous assumption that simply stripping 2 characters (ID, id, Id etc) off a field name used in a foreign key will resolve to a correctly named entity (IE: table name) that is identical to what EF6 framework generates (and quite well in my view). The EF6 Core team really needs to exactly replicate the EF6 Framework logic (IE: Create model from database). Presumably the EF6 Framework code for this is available somewhere and transplanting it into EF6 Core should be feasible. Reverse engineer isn't an area that has an impact on performance - its basically design time only. I value your insight and thoughts. It is entirely possibly I misunderstand the mechanism in EF6 Core's reverse engineer. Regardless, the end result should match EF6 Framework. |
I suggest you raise an issue in the EF Core repository, I have not been able to fidn a duplicate. I do not plan to implement anything to fix this, as any fix will break existing code, and will be hard to get right. You can use the bulk renaming feature to strip of of the weird "GUID" ending. |
Agreed and understood. This is primarily and issue in EFcore's functionality. |
That does not sound like a viable alternative, I would look into using to global rename feature to replace words ending on GUID with GUIDID. |
This has been fixed in EF Core 7 |
Using Reverse Engineer to migrate from EF6 .Net Framework with EDMX and all its good stuff to EF6 Core.
I have some very large databases that have primary key fields and FK field names that end in "GUID". EG: UserGUID, OrderGUID etc. When Power Tools runs the reverse engineer it applies unexpected names to the virtual properties.
Example tables:
Users and UserLogins
The generated UserLogin class includes virtual property for User named as UserGU
EG: public virtual User UserGU { get; set; }
The same issue applies to unusal names for one to many where the collection will be name something like:
public virtual ICollection TrusteeOwnerUserGUs { get; set; }
Instead of something more like TrusteeOwners.
There is considerable difference between what EF6 Framework generates when using database first to generate the EDMX and classes.
That's a really tough migration issue in any large application. This is especially true with respect to the collections. Not clear to me what the EDMX logic is for the relation naming, but that did set a standard at least for our shop.
I am including a VS2022 solution that has both a EF6 core class library and an EF6 Framework class library along with a SQL database creation script in the hope you can investigate and ideally arrive at something that will duplicate the naming that EF6 Framework generates (even if that is a new option). The alternative is a huge hill to climb migrating to Core and combing through gigabytes of code to adjust names.
Example:
Steps to reproduce
Load the attached VS2022 solution. Refer to EFtools class library and EFframework library in the solution.
Review the 3 classes in each project: User, UserLogin, Trustee, paying attention to any virtual property and the naming differences.
Clearly the stuff that ends in "GU" seems incorrect (or at least undesirable).
Aside from that, duplicationg the naming that EF6 Framework produces would be the most preferred outcome.
Further technical details
EF Core version in use: EF Core 6
EF Core Power Tools version: 2.5.832
Database engine: SQL Server 2014
Visual Studio version: Visual Studio 2022 17.0.1
EFtoolsDBcreate.zip
EFtoolsTestSolution.zip
Thanks for your time! Great tool. Hope we can get this tweaked out...
Scott
The text was updated successfully, but these errors were encountered: