I understand your point about relying on the API, but that is not what I am talking about.  I am not deleting Users in my own code, I am using the DNN UI to do that.

What I am referring to is that there are hundreds of third party modules that use 'UserID' as a foreign key to the Users table and have referential integrity imposed by the database to ensure that when a User is deleted from the table, the User's related data in the third party module is also deleted. 

For example,

SELECT  * 
FROM myCustomers
WHERE myCustomers.UserID=UserID (passed in from Context)

This recent change is a MAJOR change in behavior.  It is made worse by the fact that there is no way to force to the old behavior (direct hard delete).   It is further made worse by the fact that there no way to even clear out soft deletes, or even restore a soft deleted user.  What is point of having a soft delete without functionality to reverse the soft delete? The soft delete functionality is a nice thought but it is not very useful without this basic level of functionality and should not have been rolled out until the full functionality set (restore soft delete, clear soft delete, etc) was complete.

As for third party modules, what do you suggest?  Unless there is a hard delete on that record, there is no way for the module business logic to know that the User is 'deleted' without changing ALL of the third party modules SQL to now also check the IsDeleted flag in UserPortals before pulling their module data.

For example,

SELECT * 
FROM myCustomers
WHERE myCustomers.UserID = UserID (passed in from Context)
AND myCustomers.UserID = PortalUsers.UserID  (new)
AND PortalUsers.PortalID = PortalID    (new)
AND PortalUsers.IsDeleted = false (new)

See the problem?  This is a breaking change for hundreds of third party modules and it is not realistic to expect them all to make changes to their SQL to support this change.
 

While I agree that modules should not directly access core tables outside of public API methods nor create foreign key relationships on core tables as a general rule, one case that requires a foreign key relationship/cascade deletes is that of ModuleID. At the moment, there is still no other way by which data for a particular module instance can be deleted upon removal of a deleted module from the recycle bin. Reluctantly, I include creation of a FK relationship on UserID back to the DNN Users table in those few situations for which no API option currently exists. Even adding an IsDeleted flag check to a module's SQL scripts still ties into a particular data provider.

Ideally, what we need are additional interfaces/events that a module can implement to be notified when a module is deleted (from a page or from recycle bin), when a user is created/deleted (soft or hard), etc.

I also question how many modules - core or third party - actually have had dataproviders other than for MS SQL written for them.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner