----- Ursprüngliche Nachricht ----- Von: Tim Bunce Gesendet: 11.08.12 12:01 Uhr An: Jonathan Leffler Betreff: 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: > > 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 Yes, I am now against the name, too, it is also too generic. > > 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. Thanks for the suggestions, how about DBIx::Table::AppendTestData or DBIx::Table::AddTestData? > 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. You are right, what was described in the usage of the module will not be the final interface, it was more or less copied over from the usage of the corresponding PL/SQL procedure. There are already too many parameters in the exported method, things need to be more modular. Thank you for the suggestion, it makes much sense to add methods available for overriding, e.g. one for handling the generated records or one for logging purposes or maybe some methods controlling the selection of data. The last point was something which was done hard coded in the PL/SQL procedure, we needed to make sure certain fields were NOT changed in the process. I am sure users of the module would have that need too. It would be nice to add such a filter method (default action: don't filter at all) meant to be overridden. The same applies to an input filter, right now, selections are done randomly on the corresponding tables, but perhaps one would like to restrict that. > 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 I will talk to that list too, thanks.
