Normally, developer should care if the entity is soft delete and apply index based on it, like b.HasIndex(e => new { e.Name, e.IsDeleted }).IsUnique();
However, this is also not the final solution. Think that you have deleted an entity named "Foo", then created another entity with name "Foo", then you can not delete it since there will be two deleted "Foo" in this case.
I didn't know b.HasIndex(e => e.Name).IsUnique().HasFilter("[IsDeleted] != 1"); usage, but it seems a good solution at least for some databases. However, I think this is not ABP's job and developer should care about it. We may create an extension method for HasFilter("[IsDeleted] != 1") at most and document it.
We agreed that this is not ABP's job and the developer should take care of it.
We are also considering the documentation, but HasFilter(“[IsDeleted] != 1”) is not supported by all databases, so we do not plan to provide such an extension method for now. However, we can provide additional information for those who want to ensure that username or email is unique at the database level, but I am not sure how much it is necessary. Because ABP already guarantees uniqueness at the application level and already covers most scenarios. As a best practice, as you said, it should also be at the database level, but we cannot add it due to the above problems. Nevertheless, we will consider adding it as a note to the document. Thanks for your understanding.
Hi,
You can find the log records on C:\Users\{USERNAME}\.abp\studio\cli\logs.
Hello again, after a short discussion, we agreed on the following opinion:
https://github.com/abpframework/abp/issues/1181#issuecomment-497723988
Thanks ❤️
Thanks for the reply. Of course, we are aware that we can add this protection ourselves, but I opened this topic since ABP is not guaranteeing this behavior ( unique users). I think you should probably update the documentation in this case and let users know that they have to think about this situation.
I will inform the relevant team member to consider this. Thank you for your suggestion.
Regarding what you said with the soft delete and tenancy, in SQL you have filtered indexes, in the sense that you can say that a deleted user is not covered by the unique index ( where IsDeleted = 0 ). Also for multi tenancy, the unique index can be a combination of Username + TenantId.
Yes, I agree, it could be. We can also consider that. As far as I remember, it was already like this in the old versions of ABP, but then we removed it due to some problems.
I am closing this issue for now, but I will definitely share what you said with my teammate and we will inform you here if necessary. Thank you.
Hello,
If you want, you can add it to your application. However, we do not add it by default because when we add this constraint, soft deleted data or users belonging to the tenant must be unique, which is not a situation we want.
Hi,
Everything looks normal. Do you also get an error when you try to download only the source code of a module?
Hi,
Unfortunately, I couldn't reproduce these errors. Here is my account folder:
https://drive.google.com/file/d/1E0vCbFc7g31d5BXaUrx8UC82_EvJVyT4/view?usp=sharing
Yes, you are right.
Sorry, I had changed the value in the wrong place on the web, in the Standard Editions Features. Now, I have changed the value in "Manager Host Features" and that's correct.
I am glad it is working.
Please, cloud you tell me how I can block the login, using the feature loginEnabled and if role is not admin?
Normally, you should to open a separate ticket for this, but if I need to give brief information, you can override the OnPost method of the Login page model and add the logic you want before calling base.OnPost.
Here are the related contents:
Closing the issue. Feel free to create a new issue if you have further questions.
Reproduction is 1/2 way there ;-). Note the screencaps of the "variable" missing during the forced debug. I think there is a hash/array that went out of bounds and everything breaks. Probably i went past original-designed upper bounds of "normal app use" and moved us in to edge/extreme. "128 fields, yeah! thats enough!". Nope.
This is a manufacturing floor Line-of-business app. The dashboard will-have literally 300 fields once pivoted.
Yes, I have been working as an ABP maintainer for 5 years, but this is the first time I have come across such a case. But we like edge cases :)
We will examine your problem and try to return as soon as possible. Thank you for your patience.
