Skip to content
vanstyn edited this page Jan 25, 2013 · 3 revisions

AuditAny provides a different API than typical DBIC components. AudityAny is used by attaching an "Auditor" to an existing schema object instead of loading at the schema/result class level (i.e. with load_components):

 my $schema = My::Schema->connect(@connect);
 
 my $Auditor = DBIx::Class::AuditAny->track(
   schema => $schema, 
   track_all_sources => 1,
   collector_class => 'Collector::AutoDBIC',
   collector_params => {
     sqlite_db => 'db/audit.db',
   }
 );

The rationale of this approach is that change tracking isn't necessarily something that needs or should be defined as a built-in attribute of the schema class, and it is more convenient and flexible than creating extended classes to achieve that separation/abstraction. Additionally, because of the object-based approach, it is possible to attach multiple Auditors to a single schema object with multiple calls to DBIx::Class::AuditAny->track. That functionality also makes AuditAny a nice/easy debug tool as various kinds of tracking can be thrown on a db with minimal interference with the rest of the code and setup time.

Future

AuditAny could be extended to also provide the traditional DBIC module interface via __PACKAGE__->load_components if this is deemed important. The way I would envision implementing this would be to make it a sort of 'macro' to automatically attach an Auditor, but still use the same dynamic plumbing, which uses Class::MOP calls to hook onto methods (around modifiers) instead of inline/overridden subs that call $self->next::method(@_).

Discussion

Are there any problems with this approach, other than convention? Are there cases with schema/result classes with their own method modifiers and hooks that will break or otherwise not mesh properly under this design that I haven't thought of? (this is in the TODO list of needed test cases).

Besides the flexibility reasons for this design, I must admit that I have often struggled with the C3 stuff and fighting load/ISA orders, etc, and that played a part in my design decision. There have been times where things just didn't do what I expected and I could never fully figure out why. Class::MOP on the other hand has been very reliable and predictable for me, and not "voodooish". I am sure I just need to learn more about C3.

Clone this wiki locally