-
Notifications
You must be signed in to change notification settings - Fork 11
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
Disable Naming Scheme? Is there a way I disable the naming scheme for ALL entities (except the enum types) #24
Comments
Couldn't you just omit |
I will give that a go and see, I think the reason why I did that was either because:
I will be able to test this in a few days and see, I ended up spending to much time being 'fancy' with configurations and using Now I just use I will test your recommendation and let you know. What would be really cool, would be some sort of SourceGenerator that was a hybrid option of your library, SmartEnum, and also 'SourceGeneration', so that a Database developer, or perhaps user, could add a new entry into the LookupTable within a database, then the Source Generator would 'read' the database, and generate an Enum or SmartEnum to go with it. This way, you loose the constraint on 'Code is Law', and can also use the database. Source Generators are a bit of a pain, so the tool could even be 'stand-alone', similar to a classic Sorry for rant, just been thinking about that feature for a bit. Thanks for the advice, I will give it a try and report back. If there is no activity on this for a while, we can close the ticket. Thanks |
Understandable... you should consider The latter one will just rename all tables - we used this for postgres table names like "user_accounts". You can use the first one without
SourceGenerators are great, challenge here is that we are querying the ef model for metadata (see here) so it's more a runtime operation than a compile time operation. I don't know if there are already existing solutions for that (accessing ModelBuilder within a SourceGenerator). |
I agree with the joys and very much pure painful experiences with source generators haha. I am wondering if you are overcomplicating things with 'hooking into' the
In my head, that's all it would do. So somewhere you must specify a class like: // You could even do by 'convention' of having the Lookup prefix
// or LU_ as an example
[SomeIdentifierAttributeLinkingItToDbTable(SomeConfig.Param)]
public sealed partial class LookupCreditCardAuthorizationStatusEnum :
SmartEnum<LookupCreditCardAuthorizationStatusEnum, Guid>
{
} Then the source generator would 'simply' (with source generators, this is a funny word -- with classic code-gen, its much easier):
public partial sealed class LookupCreditCardAuthorizationStatusEnum : SmartEnum<LookupCreditCardAuthorizationStatusEnum, Guid>
{
public static readonly LookupCreditCardAuthorizationStatusEnum Disabled = new(
nameof(Disabled),
Guid.Parse("A4D1A3D6-EB35-44CE-8D8A-3A9ED9FEC169"));
public static readonly LookupCreditCardAuthorizationStatusEnum Failed = new(
nameof(Failed),
Guid.Parse("0EFBE9B2-5ADF-4401-B307-6D7F46644B57"));
public static readonly LookupCreditCardAuthorizationStatusEnum Expired = new(
nameof(Expired),
Guid.Parse("1169ED73-5E8C-4655-9449-A9C7F4A42DBA"));
public static readonly LookupCreditCardAuthorizationStatusEnum Active = new(
nameof(Active),
Guid.Parse("62750D9A-F0C8-4A81-AA15-D2D102AF5A99"));
public static readonly LookupCreditCardAuthorizationStatusEnum PendingVerification = new(
nameof(PendingVerification),
Guid.Parse("FC966769-80D1-40B8-A552-E8630207B613"));
private LookupCreditCardAuthorizationStatusEnum(
string name,
Guid value)
: base(name, value)
{
}
} In this example, I only have (2) columns:
You can add more columns and such, and make it fancier, or more simple. This was how I designed it in my head, I didn't see any need to use the
As of now, all of this is just concept, I don't have any code for this written, but I do love code-generators and am a contributor of Testura.Code in addition to having my own libraries
Thanks for this, this clears things up alot. I very much want to use this library, I will write some documentaiton for it once I implement it. Your advice on what its really cool to see you guys so active, I see a few of your team members in the issues of Thanks again! |
I was thinking this with our library in mind (migrating it to source generators), which does the following:
But you are right - with marker attributes we could omit the first part, and generate the source code for 2) and 3) as Your suggestion / addition would be to go the other way round and specify the enum values from the data in the database? I have heard about but never used
Too kind 😃 |
Hello!
I'd like to configure my database table naming scheme manually within my
IEntityTypeConfigureation<>
classes. I don't wantSpatialFocus/EntityFrameworkCore.Extensions
to apply any NamingScheme to any non-enum classes at all.For context, this is my use-case
SpatialFocus/EntityFrameworkCore.Extensions
for the enum to table featuresSpatialFocus/EntityFrameworkCore.Extensions
to work with enums in this table capacitySpatialFocus/EntityFrameworkCore.Extensions
to touch my other 'non-enum' tablesIs it possible to disable this without manually selecting all entities to exclude?
This is the result if I specify:
If I do not specify the above code snippet, then all tables will be styled to the configuration of the
enum
which in this example issnake_case
withClrType
The text was updated successfully, but these errors were encountered: