Pluggable/dynamic data processing/munging/transforming perl module?

Cross-posted from perlmonks:

I have to clean up some gross, ancient code at $work, and before I try to make a new module I'd love to use an existing one if anyone knows of something appropriate.

At runtime I am parsing a file to determine what processing I need to do on a set of data.

If I were to write a module I would try to do it more generically (non-DBI-specific), but my exact use case is this:

I read a SQL file to determine the query to run against the database. I parse comments at the top and determine that

• column A needs to have a s/// applied,
• column B needs to be transformed to look like a date of given format,
• column C gets a sort of tr///.
• Additionally things can be chained so that column D might s///, then say if it isn't 1 or 2, set it to 3.

So when fetching from the db the program applies the various (possibly stacked) transformations before returning the data.

Currently the code is a disgustingly large and difficult series of if clauses processing hideously difficult to read or maintain arrays of instructions.

So what I'm imagining is perhaps an object that will parse those lines (and additionally expose a functional interface), stack up the list of processors to apply, then be able to execute it on a passed piece of data.

Optionally there could be a name/category option, so that one object could be used dynamically to stack processors only for the given name/category/column.

A traditionally contrived example:

$obj = $module->new();  
$obj->parse("-- greeting:gsub: /hi/hello"); # don't say "hi"  
$obj->parse("-- numbers:gsub: /\D//"); # digits only  
$obj->parse("-- numbers:exchange: 1,2,3 one,two,three"); # then spell out the numbers  
$obj->parse("-- when:date: %Y-%m-%d 08:00:00"); # format like a date, force to 8am  
$obj->stack(action => 'gsub', name => 'when', format => '/1995/1996/'); # my company does not recognize the year 1995.  

$cleaned = $obj->apply({greeting => "good morning", numbers => "t2", when =&开发者_StackOverflow社区gt; "2010116"});  

Each processor (gsub, date, exchange) would be a separate subroutine. Plugins could be defined to add more by name.

$obj->define("chew", \&CookieMonster::chew);  
$obj->parse("column:chew: 3x"); # chew the column 3 times  

So the obvious first question is, does anybody know of a module out there that I could use? About the only thing I was able to find so far is [mod://Hash::Transform], but since I would be determining which processing to do dynamically at runtime I would always end up using the "complex" option and I'd still have to build the parser/stacker.

Is anybody aware of any similar modules or even a mildly related module that I might want to utilize/wrap?

If there's nothing generic out there for public consumption (surely mine is not the only one in the darkpan), does anybody have any advice for things to keep in mind or interface suggestions or even other possible uses besides munging the return of data from DBI, Text::CSV, etc?

If I end up writing a new module, does anybody have namespace suggestions? I think something under Data:: is probably appropriate... the word "pluggable" keeps coming to mind because my use case reminds me of PAM, but I really don't have any good ideas...

• Data::Processor::Pluggable ?
• Data::Munging::Configurable ?
• I::Chew::Data ?

---

First I'd try to place as much of the formatting as possible in the SQL queries if possible. Things like date format etc. definitely should be handled in SQL.

Out top of my head a module I know and which could be used for your purpose is Data::FormValidator. Although is is mainly aimed at validating CGI parameters, it has the functionality you need: you can defined filters and constraints and chain them in various ways. Doesn't mean there no other modules for you purpose, I just don't know.

Or you can do something what you already hinted at. You could define some sort of command classes and chain them on the various data inputs. I'd do something along these lines:

package MyDataProcessor;

use Moose;
has 'Transformations' => (
    traits => ['Array'],
    is => 'rw',
    isa => 'ArrayRef[MyTransformer]',
    handles => {
        add_transformer => 'push',
    }
);

has 'input' => (is => 'rw', isa => 'Str');

sub apply_transforms {  }


package MyRegexTransformer;

use Moose;

extends 'MyTransformer';

has 'Regex' => (is => 'rw', isa => 'Str');
has 'Replacement' => (is => 'rw', isa => 'Str');

sub transform {  }

# some other transformers
#

# somewhere else
#
#

my $processor = MyDataProcessor->new(input => 'Hello transform me');

my $tr = MyRegexTransformer->new(Regex => 'Hello', Replacement => 'Hi');

$processor->add_transformer($tr);

#...

$processor->apply_transforms;

---

I'm not aware of any data transform CPAN modules, so I've had to roll my own for work. It was significantly more complicated than this, but operated under a similar principle; it was basically a poor man's implementation of Informatica-style ETL sans the fancy GUI... the configuration was Perl hashes (Perl instead of XML since it allowed me to implement certain complex rules as subroutine references).

As far as namespace, i'd go for Data::Transform::*

---

Thanks to everyone for their thoughts.

The short version: After trying to adapt a few existing modules I ended up abstracting my own: Sub::Chain. It needs some work, but is doing what I need so far.

The long version: (an excerpt from the POD)

=head1 RATIONALE

This module started out as Data::Transform::Named, a named wrapper (like Sub::Chain::Named) around Data::Transform (and specifically Data::Transform::Map).

As the module was nearly finished I realized I was using very little of Data::Transform (and its documentation suggested that I probably wouldn't want to use the only part that I I using). I also found that the output was not always what I expected. I decided that it seemed reasonable according to the likely purpose of Data::Transform, and this module simply needed to be different.

So I attempted to think more abstractly and realized that the essence of the module was not tied to data transformation, but merely the succession of simple subroutine calls.

I then found and considered Sub::Pipeline but needed to be able to use the same named subroutine with different arguments in a single chain, so it seemed easier to me to stick with the code I had written and just rename it and abstract it a bit further.

I also looked into Rule::Engine which was beginning development at the time I was searching. However, like Data::Transform, it seemed more complex than what I needed. When I saw that Rule::Engine was using [the very excellent] Moose I decided to pass since I was doing work on a number of very old machines with old distros and old perls and constrained resources. Again, it just seemed to be much more than what I was looking for.

=cut

As for the "parse" method in my original idea/example, I haven't found that to be necessary, and am currently using syntax like

$chain->append($sub, \@arguments, \%options)