Dave,
Yes really good points - I forgot about the unique constraints. In fact I had hoped to catch you on IRC before posting!
In point of fact I think that the plan would not have been to use expired_p for the reasons you stated but to create a deleted_p. However this idea really only takes care of new visitors who enter some registration details so still leaves the problem of a general solution open - and in fact would make the general solution harder to implement in the future.
The most elegant solution as far as I can see is in fact to add delepeted_p to acs_objects since this is the correct place semantically to store object meta-data.
If we are dealing with the addition of a single dichotomous value (i.e. a small integer column) I cannot imagine that this would be a big performance hit. Certainly it would be better than storing ams attributes for this purpose on a package specific basis.
The devil would probably be in the way that other applications request the information from the core. The field may need to be carried throught to another table or two in order to avoid joining to acs_objects.
One other issue would be how this would impact the permissions tables. Is there a cheeky way of using the permissions system to tell you that an object is deleted without visiting acs_objects (a magic permission for deleted objects) or do we take all steps to ensure that any change to acs_objects is designed to avoid touching the permissions tables at all?
R.
