Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Neither here nor there 1 Comment More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • how tidy (Score:3, Interesting)

    by wickline (135) on 2003.03.11 15:15 (#17880) Journal
    Does your auditing need to be concise?

    Maybe you could just follow caller() until it returns undef (or up to some appropriate max if that's a worry)... or follow caller() until it's tracked back to some srcript?

    Or maybe it's time for Yet Another Level of Indirection, so that auditable things all go through an API which requires the appropriate audit log data.
        app -> YALI -> Class::DBI
                   `-> auditing (as needed)
    you wrote:

    The product object shouldn't be collecting information about which application is using it or who is making the changes (should it?).


    I've had objects (not with Class::DBI) which tried to determine who was modifying them. This wasn't a critical audit thing, but just for purposes of advisory record-change collision notices ("Bob just saved that record 2min ago and you'll want make changes from that more recent version"). In that case, each record had this metadata, and so it made sense (to me) for the object to gather that info. If I needed auditing, I would have stuck it in the object in that case.

    I dunno... five hours of sleep in three days leaves my mind tending to wander a bit, but I don't think it's a universal evil for the object to care about who does what to it.

    -matt
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.