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

Is the Reverse engineering tool generally intended to be used once? #365

Closed
netbitshift opened this issue Apr 11, 2020 · 5 comments
Closed

Comments

@netbitshift
Copy link

My typical workflow will typically involve adding/updating a few tables, then Reverse eng with the tool to update my model. There are close to 100 tables in the Db, with a handful of them I have added custom attributes on the Data annotations, eg.
[Required] to [Required(AllowEmptyStrings = true)]
This is to get around the issue of having non-null varchar field but allow empty strings on a few selected fields.

If I simply follow the Reverse eng path, I need to select the tables to be generated, which is used to recreate the entire db model/context. I get that, but I suppose what Im wondering is if there is a way to reverse eng only a handful of tables (to reflect the schema changes in the Db for those tables), rather than all or nothing. If I do the latter, then I loose those custom annotations that were added earlier to tables that are not part of the current set of changes Im working on, and they must be added back manually. Granted its only a handful, but it gets me out of the UI workflow.
Hope that helps.

Another suggestion possibly, is to allow custom generation of a handful of entities, where I could specify those custom annotation attributes?

So I guess my question is this: Is the reverse engineering tool option, generally used once eg. when creating a new project?

Thanks again, and love the tool!

@ErikEJ
Copy link
Owner

ErikEJ commented Apr 12, 2020

You can choose to only generate Entities, and then only some - would that work for you? (They would of course need to be part of your DbContext already) - I use the feature continously. But I do not use (or worse modify) DataAnnotations.

@ErikEJ
Copy link
Owner

ErikEJ commented Apr 12, 2020

NTW, there is a discussion about Required annotation here, that you may find relevant: #348 - you sound like you have yet another take on it (AllowEmptyStrings = true)

@netbitshift
Copy link
Author

netbitshift commented Apr 12, 2020

Hi Erik,

Ah, I had forgot that option was there, on the last screen "what to generate", with the options:
DbContext and Entities, DbContext only, Entities only .
I had typically chosen DbContext and Entities and not thought about changing it.

image

My typical workflow - involves making a few table changes, then running the tool again, selecting all the tables I need in my model. With the option "DbContext and Entities" picked, only those tables selected will be in the model. So If I was to choose "Entities only", will any entities already generated be preserved and not deleted?
In other words, if my model currently contains entities A, B, C and D, if I choose Reverse Engineer > choose entities A, B and C but not D, then DbContext and Entities, only A,B & C will be in my model, D being removed, correct?
If however, I choose Reverse Engineer > choose entities A, B and C but not D, then Entities only, only A, B & C will be regenerated while leaving D intact?

Regarding your 2nd comment above, yes, this is related and the same issue that I am having with the emptystrings/required attributes, and I had read through that and its related threads both here and over on the EF github regarding scaffolding and default constraints etc.

The whole issue came up because there are a few tables that contain a limited number of varchar fields are marked not null but the requirements are that a record allow empty strings. So I modified the attributes on those entites, but those changes will get blown away when the model/dbcontext is regenerated. This might not happen for weeks or months later when that particular table/entity is regenerated and I had not made a note of making the custom changes.

So in short, there are two things I am trying to address:
(1) selectively regenerate only specific entities to reflect the underlying schema change, but not delete any existing entities. Sounds like youre saying that choosing "Entities only" will do that?
(2) find a way to handle non-null varchar fields to allow empty strings but without having to manually modify the auto-generated entitiy and thus break the ui workflow via reverse engineering

@netbitshift
Copy link
Author

@ErikEJ just to update, I can confirm the "entities only" option, just tried that and will alleviate alot of the problems I was running into having custom attributes getting overwritten. That works! Just updated a table and did the rev eng step with only that entity selected and only that entity was regenerated, while leaving the others unchanged.

On the other front, I think one solution mention in another post was to handle this non-null empty string issue was to somehow generate the AllowEmptyStrings = true when there is a default constraint applied. The threads I read on that is that is not so simple and might involve the EF Core team updating the scaffolding features? Either way, that would be great but at least for now, I can work around it now that I have a way to rework schema changes back into my model for a limited number of entities WITHOUT blowing away other entities.

@ErikEJ
Copy link
Owner

ErikEJ commented Jun 24, 2020

Have a look at this: #412 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants