Re: Is DBIx::Table::Inflate a good name for a CPAN module?

On Fri, Aug 10, 2012 at 05:27:47PM -0700, Jonathan Leffler wrote:
> On Sun, Aug 5, 2012 at 12:48 PM, "José Diaz Seng" <[email protected]>wrote:
> 
> > I am about to write a CPAN module having the working title
> > DBIx::Table::Inflate and would like to hear your opinion about the name.
> >
> >  Your comments are very welcome, especially recommendations against the
> > name or alternative names (and also any other suggestions regarding the
> > capabilities of the module). I have read the module naming guide and posted
> > a pretty detailed description of the module to the perl modules mailing
> > list, see the tread starting with
> > http://www.nntp.perl.org/group/perl.modules/2012/08/msg81608.html .
> >
> >  brian d foy suggested that I talk to this mailing list too to get
> > additional advice, so I did.

> The module exposes only one method inflate() which can be used to add
> records to a table, mainly with performance tests of database clients
> in mind. inflate() automatically takes into account the different
> types of constraints on the target table and tries to generate
> meaningful records by using values coming from the target table itself
> or from referenced tables. A sample usage (subject to changes) looks
> like this:

> > use DBIx::Table::Inflate;
> >
> > my $inflation = DBIx::Table::Inflate->new();
> >
> > $inflation->inflate({
> >  dbh =>$dbh,
> >  table_name => $table,
> >  target_size => $size,
> >  num_random => $random,
> >  max_tree_depth => $depth,
> >  min_children => $min_children,
> >  min_roots => $min_roots
> >  });
> >
> >  The parameters are as follows:
> >
> > dbh: DBI database handle
> > table_name: name of the table to inflated
> > target_size: total number of records to be reached
> > num_random: The first num_random number of records use fresh random choices for their values taken from foreign key relations or from the target table itself. For performance reasons, these values are stored in a cache and re-used for the remaining target_size - num_random records.
> >    the last three parameters become relevant only in case of self-references of the target table (current definition of a self-ref: one-column wide foreign key constraint to itself:
> > max_tree_depth: maximum depth at which new records will be inserted
> > min_children: minimum number of child records to be inserted (currently using a breadth-first traversal)
> > min_roots: the minimum number of root elements defined after completion. A record is considered to be a root element if the corresponding parent id is null or equal to its child id

> As already mentioned, there is a module DBIx::Table::Dup; this module fits
> into the same general namespace reasonably sensibly.  I'm not
> over-enthusiastic about the name 'Inflate', but at the moment I don't have
> a good alternative.

The term inflate is already closely associated with other kinds of
actions so wouldn't be a good choice for this module.
See http://search.cpan.org/search?query=inflate&mode=all

> I don't know whether a name such as
> DBIx::Table::DataGenerator would be better?  Given that you have a database
> handle, I assume it actively loads the data, rather than generating a file
> for later loading.  Thus, it is arguably a
> DBIx::Table::DataGeneratorAndLoader, or even
> DBIx::Table::TestDataGeneratorAndLoader, but that gets rather unwieldy.
> (OTOH, the ideas might set your thought processes in motion.)  If the
> module is renamed, would you rename the method too?

DBIx::Table::TestDataGenerator seems reasonable. Or perhaps
DBIx::Table::TestDataPopulate.

> The overall functionality looks reasonable (and the recursive table
> structure handling is interesting).
> 
> I'm not sure if you would want to allow the user to specify a seed (for the
> PRNG), so that they can get deterministic results, or provide a mechanism
> to allow them to retrieve the seed used (or both).  Have you considered an
> option to specify the size of transaction (to avoid overwhelming the
> database and its logs)?  Have you considered what information goes in the
> 'table name'?  Does it allow for 'owner' or 'schema' or similar, or should
> that be specifiable separately?

All good advice.

You're already using an object, so you could allow further control by
defining and documenting methods that could be overridden in a subclass.

Rather than thinking in terms of providing a solution, it's good to
think in terms of providing a kit of parts that's already configured for
one common use-case.

The dbix-class mailing list might be a useful place to discuss what
you're doing. They're likely to know about related modules and ideas.
http://lists.perl.org/list/dbix-class.html

Have fun.

Tim.