Dear ABP Support Team,
I'm seeking clarification on the recommended naming convention strategy when using ABP Framework with PostgreSQL.
While PostgreSQL standards typically use snake_case, we've encountered several challenges when applying this to ABP entities:
1. Inconsistent Casing Enforcement:
* UseSnakeCaseNamingConvention() doesn't fully handle inherited properties (e.g., IsDeleted, CreationTime from FullAuditedAggregateRoot)
* Some generated queries still reference PascalCase names
2. Migration Conflicts:
* Built-in ABP queries expect PascalCase table/column names (SELECT * FROM "AbpPermissions")
* This causes failures when the physical schema uses snake_case
3. Current Workarounds:
* We've tried creating PostgreSQL views as aliases
* Implemented custom IEFCoreNamingConventions
* Used interceptors to rewrite queries
Could you please clarify:
* The officially recommended approach for PostgreSQL naming conventions?
* Whether there are plans to improve snake_case support in future versions?
* Any known workarounds for the FullAuditedAggregateRoot property casing issue?
This would help us align our implementation with ABP best practices.
Best regards,
3 Answer(s)
-
0
ABP Framework does not enforce a specific naming convention for PostgreSQL schemas by default. The official documentation and community articles confirm that ABP uses PascalCase for table and column names out of the box, which aligns with .NET conventions but not with PostgreSQL's typical snake_case style.
The
UseSnakeCaseNamingConvention()method from EF Core can be used to apply snake_case naming, but it does not fully cover inherited properties (such as those fromFullAuditedAggregateRoot). This is a known limitation, and some ABP internal queries and modules may still expect PascalCase names (e.g.,"AbpPermissions"), leading to migration and runtime conflicts if the physical schema uses snake_case.There is currently no official ABP guidance or built-in support for enforcing snake_case across all entities, including inherited and module-provided properties. The recommended approach is to use the default PascalCase naming to ensure compatibility with ABP modules and migrations.
Workarounds such as custom EF Core naming conventions, query interceptors, or database views are community-driven and not officially supported. These may help in specific scenarios but can introduce maintenance overhead and compatibility risks with ABP updates.
As of now, there is no official roadmap or announcement regarding improved or native snake_case support for PostgreSQL in ABP Framework. The best practice is to use the default naming conventions unless you are prepared to handle the additional complexity and potential issues with custom solutions.
For the FullAuditedAggregateRoot property casing issue, there is no officially supported workaround. If you must use snake_case, you will need to manually configure property mappings for all inherited properties and be aware of the risks with ABP module compatibility.
Sources:
- https://docs.abp.io/en/abp/latest/Entity-Framework-Core-PostgreSQL
- https://abp.io/community/articles/c9kb05dc
- https://abp.io/community/articles/g1wgv6sa
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
-
0
What will be the suggested approach if we where to stick with camel_casing?
-
0
hi
Can you try this?
GetEntityTypesandGetPropertieshttps://github.com/abpframework/abp/issues/18354#issuecomment-1840172073
Thanks
