Well specifically are the entries in all the various possibly related tables cleared out and is the deleted column in mdl_user then set to 1, or is it simply a matter of setting that column to 1?
The reason I ask is that we've now got about 21,000 users who are 'deleted'.
It would be nice to actually delete these and to know that moodle would not put up puzzling error messages or break in a less polite manner at some point.
I've searched around for info about an Entity Relationship Diagram. With a view to writing something myself.
Apparently there isn't one. The relations are implicit in the php code. How many thousands of lines?
So in essentially retaining 'deleted' users am I also retaining huge amounts of data most of which will never be viewed much less used in any way?
By the way I do understand the rationale of archiving data or setting a flag in this way rather than crudely wiping out rows from tables, but does this mean that the database will eventually become enormous?
IMO for a project as large and complex as moodle there should be an ERD and it should be maintained and adhered to in scripts.
Paul R.
The reason I ask is that we've now got about 21,000 users who are 'deleted'.
It would be nice to actually delete these and to know that moodle would not put up puzzling error messages or break in a less polite manner at some point.
I've searched around for info about an Entity Relationship Diagram. With a view to writing something myself.
Apparently there isn't one. The relations are implicit in the php code. How many thousands of lines?
So in essentially retaining 'deleted' users am I also retaining huge amounts of data most of which will never be viewed much less used in any way?
By the way I do understand the rationale of archiving data or setting a flag in this way rather than crudely wiping out rows from tables, but does this mean that the database will eventually become enormous?
IMO for a project as large and complex as moodle there should be an ERD and it should be maintained and adhered to in scripts.
Paul R.