Skip Menu |

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: 5387
Status: new
Priority: 0/
Queue: Alzabo

People
Owner: DROLSKY [...] cpan.org
Requestors: bjovanovic [...] bjovanovic.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.82
Fixed in: (no value)



Subject: Alzabo fails to do join properly if a table does not have a pk
If a join is attempted between table A, and table B, and table A does not have a primary key defined, join cursor ->next will return undef for table A object. An example: Table A: QuestionID (not defined as a primary key), QuestionText Table B: AnswerID (primary key) QuestionID (forign key, properly linked to TableA) $schema->join( join => [ $A, $B] ); will return cursor that returns [undef, "Table B row object"] ... I got this on a reverse engineered MySql database that had a similar structure. As soon as I defined what the primary key is in A, it works ok. None of the tables had primary keys defined in the DB (the DB was a dumb dump of an MSSQL), but alzabo guessed what the primary keys are for some tables. for TestQuestions, it did not manage to guess that the key is QuestionID.... Just wondering if this is a bug.. It should not impact our production enviroment since we do have a proper DB layout - the thing I was testing Alzabo on was the old system that we need to migrate the data from ... Thanks! Cheers, bojan PS Like Mason A LOT. Reported a bug or two a while ago, and got credit for it! THANKS!
PPS. Relationship was defined properly using Alzabo::GUI::Mason...
Date: Thu, 19 Feb 2004 11:41:16 -0600 (CST)
From: Dave Rolsky <autarch [...] urth.org>
To: Guest via RT <bug-Alzabo [...] rt.cpan.org>
Subject: Re: [cpan #5387] Alzabo fails to do join properly if a table does not have a pk
RT-Send-Cc:
On Thu, 19 Feb 2004, Guest via RT wrote: Show quoted text
> If a join is attempted between table A, and table B, and table A does not have a primary key defined, join cursor ->next will return undef for table A object. > An example: > Table A: > QuestionID (not defined as a primary key), > QuestionText > Table B: > AnswerID (primary key) > QuestionID (forign key, properly linked to TableA) > > $schema->join( join => [ $A, $B] ); > > will return cursor that returns > [undef, "Table B row object"] > ... > > I got this on a reverse engineered MySql database that had a similar > structure. As soon as I defined what the primary key is in A, it works > ok. None of the tables had primary keys defined in the DB (the DB was a > dumb dump of an MSSQL), but alzabo guessed what the primary keys are for > some tables. for TestQuestions, it did not manage to guess that the key > is QuestionID....
It doesn't guess, it looks at what the database tells it. I'm guessing that for some reason MySQL didn't report that table A had a PK. Show quoted text
> Just wondering if this is a bug.. It should not impact our production > enviroment since we do have a proper DB layout - the thing I was testing > Alzabo on was the old system that we need to migrate the data from ...
The bug is really that Alzabo should blow up with a more explicit error message and soon as you try to do much of anything with a table that doesn't have a primary key. A table without a primary key makes absolutely no sense, and Alzabo really can't handle it, because it needs the PK to identify individual rows and whatnot. I'll add something to the code to check for this earlier. But the fix for you is to make sure all your tables have primary keys. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/