Proposal on Soft Delete.

[Muning69]

When there are two fields in a record used to record the soft deletion time of two users, but the current soft deletion will simultaneously write these two fields to the same deletion time.

[mkll]

@Muning69 What do you mean when you say "deleting two users"? What are the two users?

If you use one record to store some attributes related to two (or more) users, whatever it is, then if this record is deleted, everything stored in it will be deleted.

[Muning69]

@mkll

tableID | user_a | user_a_deletedAt | user_b | user_b_deletedAt

For example, in the above example, I may want to record the soft deletion time of different users separately in one record.

[Muning69]

@mkll

If user A performs a soft deletion, but user B does not, user B hopes to be able to request the data normally.

[mkll]

@Muning69 SQL databases are not designed for such use in principle.

[mkll]

@Muning69 You cannot delete such a “user” by querying the database, because the database operates on the entire record, and all operations (create, update, delete) are performed on the record. The deletedAt field reflects the deletion of the entire record, not part of it.

You can delete, for example, user A at the business logic level of your application, but at the database level this will be a record update, not a delete.

If you want to put two users in one record, then all operations on them are the responsibility of your application, not the database. In this case, manipulations with users do not correlate in any way with manipulations with records. Deleting a user is not equivalent to deleting a record, your application logic is completely separated from the database logic.

Accordingly, since you are building your own logic on top of the database logic, then you should go all the way and not use predefined fields, in particular, deletedAt, but provide your own fields of similar purpose, and your own logic for processing them.

P.S. The meaning, purpose and benefits (if any) of this approach are completely unclear. However, it's up to you.

[Muning69]

@mkll
What you said makes sense.
But I think Vapor can do better in this area.
After all, soft deletion is defined by Vapor.
We should be able to come up with a more convenient soft deletion solution in this regard.

[Muning69]

@mkll
Sharing data from two users in a single record is commonly used in most cases. If adjustments can be made to this soft deletion, I believe it will become more user-friendly.
What I mean is that a certain field in the same record may be jointly owned by two users, and both parties can modify it. Therefore, if soft deletion can be defined separately, it would be more user-friendly.

[0xTim]

This is probably out of scope for Fluent (since it's a Fluent concern and nothing to do with Vapor) as it requires some application knowledge and sharing data between different entities and managing conflict resolution is not something Fluent can solve without knowing any business logic. You can implement this yourself using Fluent's model lifecycle functionality which is designed exactly for use cases like this

[mkll]

What you said makes sense.
But I think Vapor can do better in this area.
After all, soft deletion is defined by Vapor.

Yes, you are right, soft deletion is an add-on to SQL, but, nevertheless, the logic of its operation lies entirely in the SQL paradigm, and the object on which actions are performed is a record, and not some entity of a higher order.

When we "soft delete", we delete the record. Being within the SQL paradigm, we cannot operate with anything that is inside a record (excluding, of course, SELECT). We work with records and only records, since a record is the standard unit of data storage in SQL databases.

(A simple analogy: the harbor crane handling standard 40ft containers in a seaport only works with containers, it cannot unload part of the container, it does not even know what is inside the container. Worse, if we set the task of “teaching” a crane to work with the contents of a container, then we will have to provide millions and billions of different variations of this content, and even then we will not cover all possible variations.)

In exactly the same way, Fluent knows nothing about which logical entities (users, in your case) are stored in the record. And he shouldn’t know, since this is not his level of responsibility.

Sharing data from two users in a single record is commonly used in most cases...

...and is solved in a traditional way for relational databases: by introducing one-to-many relationships.

We should be able to come up with a more convenient soft deletion solution in this regard

I have to repeat once again: Fluent works with database records at the SQL level and does not know (and should not know) anything about the objects that may be inside the records. A soft delete is nothing more than a small, very lightweight addition that does not violate the principles of working with the SQL database, does not introduce any additional concepts or abstractions, and does not go beyond the SQL paradigm.

You are mistaken in thinking that the problem lies in the absence of the deletedAt field you need. The problem is much more fundamental — there is no “command” in Fluent with which you could work with nested entities, such as your “users”. Fluent works with records and only records. Returning to your example, if you want to delete “user A” using Fluent, then you will delete the whole record in which he is located. And along with the record, you will delete “user B” too, of course.