Syntactic sugar: overload deleteWithoutArchive() for archivable behavior #74
Description
Thinking further about the archivable behavior & following up on the thoughts/my suggestions in #10 - I am wondering if it makes sense to overload deleteWithoutArchive().
The reasoning is as follows:
As per default with the archivable behavior, one has the option to either:
- use delete() and the object/row "migrates" from the parent table to the archive table.
- use deleteWithoutArchive() on the parent table and the object/row gets "hard" deleted
In case the user has performed the former and now wants to finally delete the entry, he would have to do this on the archive table instead of the parent table. But he has to know about the former operation.
Imagine the following case on the other hand:
The user/program logic wants to immediately delete an object/row from the parent table and does not know the row/object has already been archived and hence deleted from the parent table. Now the user/programlogic calls deleteWithoutArchive() and this should throw an error as the entry has already been deleted from the parent table.
In my opinion, deleteWithoutArchive() could also be agnostic on the actual position of the entry. In other words, it should work regardless if the entry sits on the parent table or on the archive table. As long as the entry exists somewhere of course. And somewhere could also be a versions table - see again #10
I know, syntactic sugar is maybe not a top priority for an ORM like this - but maybe even tiny steps forward could make it more attractive again in the future in case they might ease the user experience & as long as we keep going.
Thoughts on this are welcome.
Best,
Kaspar.