«

Ivan,

I'm experimenting with the DBIx:BSchema module to copy a proprietary
DB into mysql (via an ODBC connection to the source DB).

I pull the DB schema with a variety of DBI calls, notably column_info
and primary_key. Building the DBIx:BSchema::Table is fairly
straightforward when the primary key for the table is a single column.
However, when I have a composite primary key, it fails whenever
$table->primary_key is called.

For example, in the following fragment, I try to "fool" the Table module
into accepting multiple columns as the primary key by assigning a
comma-separated list, but the sql_create_table call barfs as soon as it
accesses primary_key.

my @pri_key = $dbh->primary_key($catalog, $schema, $table);
$table->primary_key(join(',', @pri_key));

my $sql = $table->sql_create_table($dbh2);

Checking the definition of primary_key, it is specifically excluding my
attempt to "fake it" thought its use of the regexp /^(\w*)$/ (line 279
in module DBIx:BSchema::Table).

Some brief experimentation to allow primary_key to handle a comma
separated list...

sub primary_key {
my($self,$value)=@_;
if ( defined($value) ) {
$self->{primary_key} = $value;
} else {
=> $self->{primary_key} =~ /^(\w*)(,\w*)*$/
#aah!
or die "Illegal primary key: ", $self->{primary_key};
=> $2 ? $1.$2 : $1;
}
}

And the code fragment above generates the correct SQL for simple or
composite primary keys.

This seems way too simple. What else would break?

Cheers, Iain

Quoth I & L Fogg <>:
>
> => $self->{primary_key} =~ /^(\w*)(,\w*)*$/
> #aah!
> or die "Illegal primary key: ", $self->{primary_key};
> => $2 ? $1.$2 : $1;

This is wrong: $2 will only contain the last of the comma-separated
portions. Try

/^(\w*(?:,\w*)*)$/

or simply

/^([\w,]*)$/

and just using $1.

Ben

--
I must not fear. Fear is the mind-killer. I will face my fear and
I will let it pass through me. When the fear is gone there will be
nothing. Only I will remain.
Frank Herbert, 'Dune'