ABP Suite Version : 5.3.2
If you create a new entity with a primary key type of string, the generate CRUD pages does not work (the Add New page, at least in Razor mode).
The ID field is not displayed, so, the value cannot be entered and error occurs when you try to save, of course.
(The default size should be asked/entered because the default of 450 seems way too big, especially for a primary key. )
If you create records in background (directly in the DB), the update/delete feature works at least.
6 Answer(s)
-
0
@FrancoisLabelle this is being tested and I'll write you the results
-
0
Just send me your project details
- UI type: Angular / MVC / Blazor
- DB provider: EF Core / MongoDB
- Tiered (MVC) or Identity Server Separated (Angular): yes / no
-
0
Hello Albert,
Actually, I tried with Blazor and EF Core. Tiered or not, that changes nothing. MVC or Angular, same thing also.
In facts, the main problem is that the primary key (Id) cannot be exposed by default in the CRUD page. This should be made an option I think.
Id values are usually generated automatically. While it can make sense for GUID, INT and LONG, for string it makes no sense. Well, unless we could provide some kind of formula to autogenerate the Id... Another feature to add some day.
When the primary key type is string, then it makes no sense to not be able to present this field to the end user for the "add page".
But, actually, if you still do, then we cannot add a new entry because the insert will fail with a generic error message. Then, we can say that the provided application is not working.
So, I'm not sure why you have offered this type (string) without really supporting it ?!?!?
We might find this "unfinished feature" useful in some specific situations, but not in ours
At least, the documentation should make this clear that this type is not fully supported and that this feature is meant to... (?!?!)....
Regards
-
0
Why do you use string primary key? Using string as the type of primary column is not a good approach because If our values can not be generated sequentially and with an Incremental pattern, this may cause database fragmentation and decrease the database performance.
The reason we put there is, sometimes you might need to migrate from a legacy database and you may want to first populate your new database table from a legacy string ID field table. In this case, you need to either change it to Guid, auto increasing numeric fields or you need to write a logic to create a unique value for each record after the Suite code generation.
-
0
Hello Albert,
I agree that string primary key is not the best approach, and I will not persist that way since the ABP framework does not fully support this.
But in our situation, it was useful to have a human readable key because the staff refers to this code amongst others system.
The plan was to first import the legacy records and then allow them to create new ones too. I was expecting to be able to avoid coding something "special" for it and be able to use the auto-generated pages from ABP Suite but we can't.
Sadly, the more I use ABP Suite, and the more I find this tools useless and very buggy. We had great hope in this tools to help us improve our development speed, but it clearly lacks some useful advance features and the overall quality of the tool is not equal to the quality of the ABP framework itself. Hopefully the framework is more stable. But, yes, it still a good startup point for basic stuff.
Regards
-
0
my suggestion would be; create another field called
ExternalId. This will be the ID field of your legacy database and you'll use guid/int for your new table. So you can still match your legacy table with thisExternalId.
