Skip Menu |
 
rt.cpan.org will be shut down on March 1st, 2021.

This queue is for tickets about the Alzabo CPAN distribution.

Maintainer(s)' notes

Not really maintained any more. Interested in taking it over? Email the author.

Report information
The Basics
Id: 13884
Status: resolved
Priority: 0/
Queue: Alzabo

People
Owner: Nobody in particular
Requestors: Rainer.Rohmfeld [...] emuge.de
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.87
Fixed in: (no value)

Attachments


Subject: MethodMaker naming errors
Download (untitled) / with headers
text/plain 536b
We are working with a huge MySQL database (about 300 tables and more than 600 foreign key relationships). All keys ar "readable", i.e. of type char or varchar. In addition, we are using multi-column keys for some exceptional cases. We have support for 12 languages, and therefore many relationships to our "i18n" table; some tables have two or three foreign key columns to the "i18n" table. The use of MethodMaker (all methods) generates a very long list of naming errors. Attached You will find our patch for a correct name handling.
Download MethodMaker.patch
text/x-diff 2.1k
=== MethodMaker.pm ================================================================== --- MethodMaker.pm (revision 6) +++ MethodMaker.pm (local) @@ -854,30 +856,49 @@ return $p{table}->name if $p{type} eq 'table'; - return $p{column}->name if $p{type} eq 'table_column'; + return lc($p{column}->name) if $p{type} eq 'table_column'; - return $p{column}->name if $p{type} eq 'row_column'; + return lc($p{column}->name) if $p{type} eq 'row_column'; if ( $p{type} eq 'foreign_key' ) { - return $p{foreign_key}->table_to->name; + + return $p{foreign_key}->table_to->name + if lc($p{foreign_key}->columns_to->name) eq + lc($p{foreign_key}->columns_from->name); + + if (join("",$p{foreign_key}->cardinality) eq 'n1') { + return $p{foreign_key}->table_to->name. + '_'.$p{foreign_key}->columns_from->name; + } else { + return $p{foreign_key}->table_to->name.'_'. + lc($p{foreign_key}->columns_to->name); + } } if ( $p{type} eq 'linking_table' ) { - my $method = $p{foreign_key}->table_to->name; - my $tname = $p{foreign_key}->table_from->name; - $method =~ s/^$tname\_?//; - $method =~ s/_?$tname$//; + # Conflicts with foreign key name; hence use foreign_key_2 + my $method = "link".$p{foreign_key_2}->table_to->name; + #my $tname = $p{foreign_key}->table_from->name; + #$method =~ s/^$tname\_?//; + #$method =~ s/_?$tname$//; return $method; } + if ($p{type} eq 'lookup_columns') { + if ($p{foreign_key}->columns_from->name ne + $p{foreign_key}->columns_to->name) { + return $p{foreign_key}->table_to->name.'_'. + $p{foreign_key}->columns_from->name.'_'. + lc($p{column}->name); + } else { + return $p{foreign_key}->table_to->name.'_'.lc($p{column}->name); + } + } - return join '_', map { lc $_->name } $p{foreign_key}->table_to, $p{column} - if $p{type} eq 'lookup_columns'; + return lc($p{column}->name) if $p{type} eq 'lookup_columns'; - return $p{column}->name if $p{type} eq 'lookup_columns'; - return $p{parent} ? 'parent' : 'children' if $p{type} eq 'self_relation';
Date: Wed, 27 Jul 2005 10:32:35 -0500 (CDT)
From: Dave Rolsky <autarch [...] urth.org>
To: Guest via RT <bug-Alzabo [...] rt.cpan.org>
Subject: Re: [cpan #13884] MethodMaker naming errors
RT-Send-Cc:
On Wed, 27 Jul 2005, Guest via RT wrote: Show quoted text
> We are working with a huge MySQL database (about 300 tables and more > than 600 foreign key relationships). All keys ar "readable", i.e. of > type char or varchar. In addition, we are using multi-column keys for > some exceptional cases. We have support for 12 languages, and therefore > many relationships to our "i18n" table; some tables have two or three > foreign key columns to the "i18n" table. > > The use of MethodMaker (all methods) generates a very long list of > naming errors. Attached You will find our patch for a correct name > handling.
The default naming sub is really not intended to work out of the box, especially for large complex schemas. I don't really want to change it, since there's no way it can satisfy everyone, no matter how complex it gets. -dave /*=================================================== VegGuide.Org www.BookIRead.com Your guide to all that's veg. My book blog ===================================================*/
Download (untitled) / with headers
text/plain 1.7k
[autarch@urth.org - Wed Jul 27 11:32:52 2005]: Show quoted text
> On Wed, 27 Jul 2005, Guest via RT wrote: > > The default naming sub is really not intended to work out of the box, > especially for large complex schemas. I don't really want to change > it, > since there's no way it can satisfy everyone, no matter how complex it > gets. > > > -dave > > /*=================================================== > VegGuide.Org www.BookIRead.com > Your guide to all that's veg. My book blog > ===================================================*/
I do not agree with Your statement. The actual naming method, included with Alzabo-0.87, is a really trivial one with respect to foreign key and lookup methods. This naming method will fail even in the case of simple schemata with a smaller set of foreign keys. We have worked out a naming method, that is not very complex (have a look on the patch), and will work very well for many schemata. We have tested (and patched) Class::DBI and SPOPS against Alzabo. Class::DBI is not as performant as Alzabo; runtime funtionality seems to be equal after our patches for multi column foreign keys. SPOPS is a little bit faster (after our patches to foreign key method generation) but lacks functionality. So we have decided to use Alzabo, since Alzabo has in addition the schema creation interface. If You have a look on the discussion lists of Class::DBI, there is a discussion about multi column foreign keys/relationships. Tony Bowden dislikes to integrate multi column foreign keys. His arguments against the integration are not very "smashing". We thought, the Alzabo development would be a little bit more progressive. Thus again:_I do not agree with Your statement! And at least the questuin: do You not want to improve Alzabo?
Date: Thu, 28 Jul 2005 15:39:36 -0500 (CDT)
From: Dave Rolsky <autarch [...] urth.org>
To: Guest via RT <bug-Alzabo [...] rt.cpan.org>
Subject: Re: [cpan #13884] MethodMaker naming errors
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.3k
On Thu, 28 Jul 2005, Guest via RT wrote: Show quoted text
>> The default naming sub is really not intended to work out of the box, >> especially for large complex schemas. I don't really want to change >> it, since there's no way it can satisfy everyone, no matter how complex >> it gets.
> > I do not agree with Your statement. The actual naming method, included > with Alzabo-0.87, is a really trivial one with respect to foreign key > and lookup methods. This naming method will fail even in the case of > simple schemata with a smaller set of foreign keys.
I don't understand how you can disagree. I made two statements about my own thinking: 1. The default sub is (intentionally) not designed to just work for all possible schemas. 2. I do not want to attempt to do make it do so. Now, you might think I _should_ make the attempt, but I think it's a bit of a waste of time. While I could certainly come up with a naming sub that always avoided conflicts, the key here is to come up with _good_ names that work for _one specific_ schema & application. Naming is a matter of art, not technology, so I don't think it can be automated in any useful way. -dave /*=================================================== VegGuide.Org www.BookIRead.com Your guide to all that's veg. My book blog ===================================================*/


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.