Open yuriy-yarosh opened 1 year ago
hi
You can replace the IGuidGenerator
with yours. : )
@maliming I'm talking about replacing GUID's enterily, with any variable-coding capable ID format. It's simpler, for me, to drop ABP entirely, and use something more mature from the DBA perspective.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@yuriy-yarosh You can create Store Procedure name next_uuid as I do. This code work as ULID with data type is uuid. Set default Id in code: `
modelBuilder.Entity\<ResCompany>(entity =>
{
entity.Property(e => e.Id)
.HasDefaultValueSql("next_uuid()")
.HasColumnName("id");
}
`
Or you replace default IGuidGenerator with your own: `
public override void ConfigureServices(ServiceConfigurationContext context)
{
Configure
I used in my project BambooERP
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Description
GUID Generation [Documentation]() clearly says that:
There's nothing wrong with the GUID's themselves it's just they're causing RDBMS Index Bloat and inherent perf degration during index traversal. Is it possible to implement a custom GUID mapping, on top of EF Core, for Dynamic GUID Sizing ?
People do often consider ULIDs to be a better replacement, and most of the existing benchmarks show that this actually can be a perf limitation fairly often, alongside with the entropy pool leaks.
Analysis
I do like the way instagram handles their complex PKey / uuid situation with constrained 64bit keys, and I find it the most performant and flexible approach.
From DBA side of things there are really clever ways to handle such cases, even if it means extending the database engine directly. At the framework side, such issues perceived as non-critical, even if it literally means speeding up inserts about 10x times and reducing the indices about 3x times.