how to proceed with changed:
Let my try to summarise the discussion: 1) changed has a fuzzy definition, a more concise audit trail attribute should replace it. A concrete proposal is needed. David has already thought about this. Want to write it up. Do *not* call it changed:! 2) I porposed to exclude changed: from answers to normal queries. Present the changed attribute only when the query contains a special flag (like -c). The only serious problem with the proposal I have read so far is the comparison for deleting an object. This could be changed to exclude changed: attributes. Anything I am missing? Daniel
Daniel Karrenberg wrote:
Let my try to summarise the discussion:
1) changed has a fuzzy definition, a more concise audit trail attribute should replace it. A concrete proposal is needed. David has already thought about this. Want to write it up. Do *not* call it changed:!
2) I porposed to exclude changed: from answers to normal queries. Present the changed attribute only when the query contains a special flag (like -c).
The only serious problem with the proposal I have read so far is the comparison for deleting an object. This could be changed to exclude changed: attributes.
Why not just use NIC/RIPE-handles in the changed field? As long as the server didn't automatically return the corresponding person object when queried (unlike the admin-c, tech-c, etc fields unless the "-r" flag is given) this would hide email addresses from the casual database user while still providing more information for those who "need to know". Regarding the date in the changed field, doesn't the database software check that a new object doesn't have a changed date older than the existing database entry? If not, isn't this something it should do? In any case, having the date (and time?) in the changed field in a standard format (ISO 8601:1988, perhaps) would, IMHO, be useful although it should probably be added by the database software rather than by the user submitting the update. Just my thoughts..... James -- "You are not expected to understand this." Ken Thompson, Unix V6 kernel source.
Why not just use NIC/RIPE-handles in the changed field? As long as the
James Aldridge wrote: this covers only part of the functionality. Handles travel with persons when they change jobs. It would be too cumbersome to change all "changed:"-fields once a "changer" leaves the registry/company. There are ways to deal with this problem if only email addresses are used.
8601:1988, perhaps) would, IMHO, be useful although it should probably be added by the database software rather than by the user submitting the update. It could even be omitted as part of the database entry and just be returned in a (comment) line starting with '%'. It is meta-information anyway.
-Peter
Peter Koch wrote:
Why not just use NIC/RIPE-handles in the changed field? As long as the this covers only part of the functionality. Handles travel with persons when they change jobs. It would be too cumbersome to change all "changed:"-fields once a "changer" leaves the registry/company. There are ways to deal with this problem if only email addresses are used.
But the point of this discussion was that email addresses wouldn't be used in (or, at least, wouldn't appear to the casual user of) the database. If people change jobs then it should be possible to perform an inverse query on the changed field in the same way as the admin-c, tech-c, etc. to permit updating of all affected records.
8601:1988, perhaps) would, IMHO, be useful although it should probably be added by the database software rather than by the user submitting the update. It could even be omitted as part of the database entry and just be returned in a (comment) line starting with '%'. It is meta-information anyway.
If the time stamp is used to prevent out-of-sequence updates (if an update to auto-dbm gets held up in a mail queue somewhere, for example) then it has to remain part of the database entry and is not meta-information. James -- "You are not expected to understand this." Ken Thompson, Unix V6 kernel source.
James Aldridge wrote:
If people change jobs then it should be possible to perform an inverse query on the changed field in the same way as the admin-c, tech-c, etc. to permit updating of all affected records. but why should one want to change, after the fact, the information about who changed an entry in the past? Or just replace the old changed: line by a new one? That would probably give false indication about the validity of the data contained in the entry.
If the time stamp is used to prevent out-of-sequence updates (if an update to auto-dbm gets held up in a mail queue somewhere, for example) then it has to remain part of the database entry and is not meta-information. Agreed. But this is open for review. There are better prerequisites to check before modifying or deleting an entry (e.g. a hash of the object, not including any "changed" information).
Bottom line: I would like to see the latest modification date of an object in response to any database query and an indication of an entity responsible for this entry. "mnt-by" may serve that purpose if it is in there. -Peter
participants (3)
-
Daniel Karrenberg -
James Aldridge -
Peter Koch