Testing SQL and friends

2006-02-27 Thread Ovid 
Hi all,

I'm not proposing to write a Test::SQL module, but I am tired of having
the following two things not being equivalent:

CREATE TABLE foo (
  id INTEGER NOT NULL PRIMARY KEY,
  name VARCHAR(32) NOT NULL,
  title
  age INTEGER
);

And:

create table foo (
  id INTEGER   NOT NULL PRIMARY KEY,
  name VARCHAR(32) NOT NULL,
  age integer
);

Those are functionally equivalent but there are a few potential
problems with testing it. I can get a reasonably easy to debug test if
I do the following:

* Collapse all unquoted whitespace to a single space.
* Preserve newlines (so that Test::Differences will still be
meaningful)
* Lower-case all unquoted characters.

I can use Data::Record to easily split the string on spaces without
affecting quoted characters:

use Regexp::Common;
use Data::Record;
my $record = Data::Record-new({
split  = qr/\s\t/,
unless = $RE{quoted},
});
my $data = join ' ', map { lc $_ } $record-records($data);

That doesn't seem flexible enough, though. It would be useful to wrap
this in a test module whereby one can control whether or not one wants
to alter the case, ignore quoted data, preseve newlines, and so on. I
could make a plethora of test functions, but the number of possible
combinations would make them unweildy. I could have the user set the
parameters at the top of the test and change the parameters as needed.
This would make this far more flexible than simply an SQL tester.
Thoughts?

I'm thinking a name like Test::ControlWhitespace.

Also posted to http://use.perl.org/~Ovid/journal/28819

Cheers,
Ovid

-- 
If this message is a response to a question on a mailing list, please send 
follow up questions to the list.

Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

Best practice for version control of locally installed CPAN modules

2006-02-27 Thread Matisse Enzer 

I'm helping plan inmprovements to a build  deploy system and am 
wondering what people think is the best practice for handling
version control of locally-installed CPAN modules.

We have a bunch of code in version control (CVS now, moving to SVN soon)

We also have a large number of CPAN modules installed, for example:

   PPI1.110
   Test::Assertions   1.051
   Test::Harness  2.56

and we want to always install exactly those versions on new machines.

Currently we are evaluating these options:

  1) Maintain a list of the .tar.gz files and install from CPAN,
 for example M/MA/MATISSE/Text-TagTemplate-1.8.tar.gz

  2) Put the CPAN .tar.gz files in a local CPAN repository and use
 CPAN::Site to install - that way we *only* get the versions in
 our local CPAN repository and dependencies are managed by the
 module Makefile.PL / Build.PL scripts.

  3) Put the .tar.gz files in our source-code control system, and checkout
 and build each one during a release process.

  4) Build these modules on one machine and check the *built* files into
 out version control system (including *.so files - all our machines 
 are Solaris boxen)

What do other folks think?

-Matisse

Re: Best practice for version control of locally installed CPAN modules

2006-02-27 Thread Tyler MacDonald 
Hello Matisse,

I like these two ideas:

Matisse Enzer [EMAIL PROTECTED] wrote:
   2) Put the CPAN .tar.gz files in a local CPAN repository and use
  CPAN::Site to install - that way we *only* get the versions in
  our local CPAN repository and dependencies are managed by the
  module Makefile.PL / Build.PL scripts.
 
   3) Put the .tar.gz files in our source-code control system, and checkout
  and build each one during a release process.

#3 seems like the lowest maintenence. Maintaining on a .tar.gz in CVS
seems easier than integrating diffs of the newest version whenever you want
to upgrade.

#2 has it's benefits too - you could even mirror all of CPAN, and
just maintain a script with install commands to install the versions you
want;

install KWILLIAMS/Module-Build-0.27_04.tar.gz;

etc. That makes both upgrading easy and makes your build process
independant from the availablity of your favourite CPAN mirror.

Cheers,
Tyler

Re: Best practice for version control of locally installed CPAN modules

2006-02-27 Thread Dr Bean 
On Mon, 27 Feb 2006, Matisse Enzer wrote:


 I'm helping plan inmprovements to a build  deploy system and am 
 wondering what people think is the best practice for handling
 version control of locally-installed CPAN modules.

   3) Put the .tar.gz files in our source-code control system, and checkout
  and build each one during a release process.

There is some interesting advice in the subversion book.

   Linkname: Vendor branches
URL:
  http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.ht
  ml#svn.advanced.vendorbr.general

-- 
Dr Bean  There is nothing as practical as a 
 good theory.
 --Kurt Lewin

Re: Best practice for version control of locally installed CPAN modules

2006-02-27 Thread Matisse Enzer 


On Feb 27, 2006, at 8:14 PM, Dr Bean wrote:


There is some interesting advice in the subversion book.

   Linkname: Vendor branches
URL:
http://svnbook.red-bean.com/nightly/en/ 
svn.advanced.vendorbr.html#svn.advanced.vendorbr.general



Thanks - that looks interesting, although complicated :-) I'll read  
it tomorrow when I've had some sleep.


---
Matisse Enzer [EMAIL PROTECTED]
http://www.matisse.net/  - http://www.eigenstate.net/