Skip to content
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

Scaffold annotations on DatabaseModel to the generated model #6561

Closed
roji opened this issue Sep 17, 2016 · 5 comments
Closed

Scaffold annotations on DatabaseModel to the generated model #6561

roji opened this issue Sep 17, 2016 · 5 comments
Assignees
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Milestone

Comments

@roji
Copy link
Member

roji commented Sep 17, 2016

With the recent work on provider-specific migrations operations via annotations (e.g. PostgreSQL extensions), I took a look at scaffolding as well. The goal here would be to detect PostgreSQL extensions present in an existing database and scaffold them into the generated model's OnModelCreating.

Looking at DbContextWrite.AddOnModelCreating, I can't see any code dealing with annotations on DatabaseModel. For example, it doesn't seem possible for scaffolded models to have DefaultSchema set. I hope I'm not missing something.

A first step here would be for AddOnModelCreating to simply generate code for all annotations it finds on the model itself. A special case could be made for default schema (and others?), generating the prettier HasDefaultSchema rather than doing it via the generic annotation API. Once #6546 is done, it could be used in the scaffolding pipline as well to allow providers to replace generic (and ugly) annotations with provider-specific renderings.

This is really not an urgent feature - I'm sure you have more important things to do - but I wanted to put it out there and make sure I'm not missing something.

@codearoo
Copy link

I have something different on this topic to report.
Using the 1.0.0-preview2-final version, sometimes the scaffolding has a [Key] attribute in the output class, and sometimes it does not and puts the Fluent code in the Context to identify the key.

I use the --data-annotations option when running, and I can't figure out what's different about the table definitions that might cause it to do that. As I'm writing this, the only difference I can think of is that the table which does end up with the [Key] has its primary key field named "ID" while the other one's don't. But I can manually put [Key] in another table class and have it work.

@divega
Copy link
Contributor

divega commented Sep 29, 2016

@codearoo I can think of two cases in which we wouldn't generate the [Key] attribute

  • If we would should identify the key by convention without the help of the attribute (.e.g. if the property is called Id or EntityTypeName + Id).
  • If the key is composite, because we don't support the attribute for composite keys in EF Core.

@codearoo
Copy link

Well if it was by convention, then I would not expect it to also output the Fluent code that defines the key. However, exactly the reverse of what you described, a table with a field ID had the [Key] attribute generated while no other table did. But I manually changed them (the ones that have just 1 key field) and it works fine.

Are there plans to allow composite keys with the [Key] attribute?
Minor issue, just curious.

@divega
Copy link
Contributor

divega commented Sep 29, 2016

@codearoo Thanks for clarifying. Could you please create a new issue and fill in the details of any surprising behavior you are seeing? Although the title of this issue contains the word "scaffold" and "annotations", it is about something completely different.

@rowanmiller rowanmiller modified the milestones: 1.2.0, 1.1.0-preview1 Oct 6, 2016
@ajcvickers ajcvickers modified the milestones: Backlog, 2.0.0 Apr 17, 2017
@bricelam
Copy link
Contributor

bricelam commented Jun 8, 2017

@smitpatel fixed this in #8680

@bricelam bricelam closed this as completed Jun 8, 2017
@bricelam bricelam assigned smitpatel and unassigned lajones Jun 8, 2017
@bricelam bricelam modified the milestones: 2.0.0-preview2, Backlog Jun 8, 2017
@bricelam bricelam added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Jun 8, 2017
@ajcvickers ajcvickers modified the milestones: 2.0.0-preview2, 2.0.0 Oct 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Projects
None yet
Development

No branches or pull requests

8 participants