You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Kee Hinckley <na...@somewhere.com> on 2003/11/28 05:03:30 UTC

DBIx::Record set and SELECT f1.* FROM foo as f1, foo as f2...

Has anyone made that work?  I tried setting !Table or !TabJoin to 
"foo as f1, foo as f2" but all did not work well.  I finally patched 
DBIx::Database to handle table aliases, and that seems to work fine.

On a related subject, there is a value '*MainTable' which always 
seems to be the same as '*Table'.  I'm guessing that in joins it 
ought to be the first table, and then in places where -label behavior 
is being examined, it should use MainTable instead of Table.  But I'm 
just guessing.  Of course if that's the case, then it ought to be set 
by default to the first table in the !Table list, and it ought to be 
possible to override it.
-- 
Kee Hinckley
http://www.messagefire.com/         Next Generation Spam Defense
http://commons.somewhere.com/buzz/  Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: DBIx::Recordset - MySQL DeleteWithLinks() test fails

Posted by Gerald Richter <ri...@ecos.de>.
>
> So the question is: how did this test pass with the other 2 drivers
> and fail with this one?
>

If wmCLEAR is triggered it means there is an attempt to delete _all_ records
in a table. That is certainly not what the test should do. I guess there is
some argument missing, i.e. some previous fetch went wrong, so the argument
what to delete is undef.

I just runs the tests for mysql on my linux box (doing a svn up before) and
all tests pass. Not sure what is the difference at your installation.

Gerald

P.S. I send you the test.log with private mail for the mysql, maybe it helps
to compare with your test.log

--------------------------------------------------------------
Gerald Richter     ecos electronic communication services gmbh
IT-Securitylösungen * dynamische Webapplikationen * Consulting

Post:       Tulpenstrasse 5          D-55276 Dienheim b. Mainz
E-Mail:     richter@ecos.de          Voice:   +49 6133 939-122
WWW:        http://www.ecos.de/      Fax:     +49 6133 939-333
--------------------------------------------------------------
|
|   ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info
|
+-------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


DBIx::Recordset - MySQL DeleteWithLinks() test fails

Posted by Terrence Brannon <me...@urth.org>.
So far, postgres and sqlite pass the test suite. mysql is failing with 
this error:

Clear (Delete all) disabled for table : (! && !(7 & wmCLEAR)) at 
blib/lib/DBIx/\
Database.pm line 57
        
DBIx::Database::Base::savecroak('DBIx::Recordset=HASH(0x86248dc)','Clea\
r (Delete all) disabled for table : (! && !(7 & wmCLEAR))') called at 
blib/lib/\
DBIx/Recordset.pm line 2733
        
DBIx::Recordset::DeleteWithLinks('DBIx::Recordset=HASH(0x86248dc)','HAS\
H(0x8618170)','HASH(0x850f0f0)') called at blib/lib/DBIx/Recordset.pm 
line 2778
        
DBIx::Recordset::DeleteWithLinks('DBIx::Recordset=HASH(0x84da3f8)','HAS\
H(0x8624744)') called at test.pl line 1957
        
main::DoTest('mysql','dbi:mysql:princepawn','princepawn','money1') call\
ed at test.pl line 4031

test.pl:1957 is:
        $set1 -> DeleteWithLinks ({ 'id' => 1
                                                })  or die "not ok 
($DBI::errst\
r)" ;

Recordset.pm:2778 is:
                      $$updset -> DeleteWithLinks ({$lf => $mv}, $seen) ;

Recordset.pm: 2732-2833 is:
  my $clear_disabled_diag =
      "(!$expr && !($self->{'*WriteMode'} & wmCLEAR))";
    $self -> savecroak ("Clear (Delete all) disabled for table 
$self->{'*Table'\
}: $clear_disabled_diag") if (!$expr && !($self->{'*WriteMode'} & 
wmCLEAR)) ;

I added the diagnostic string to the croak message so it would be clear 
why the
exception is being thrown. It is being thrown because the WriteMode must 
be 8 for it
to bitwise-and to a true value with wmClear.

So the question is: how did this test pass with the other 2 drivers and 
fail with this one?




---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: DBIx::Record set and SELECT f1.* FROM foo as f1, foo as f2...

Posted by Terrence Brannon <me...@urth.org>.
Kee Hinckley wrote:

> Has anyone made that work?

http://princepawn.perlmonk.org/cgi-bin/se.com/wiki.cgi?RecordsetUpgradePath

Patch #4 by Angus Lees:

.#4 fully-qualifying column names and column alias patch (angus lees) . 
+ http://www.ecos.de/~mailarc/embperl/2002-01/msg00006.html 
<http://www.ecos.de/%7Emailarc/embperl/2002-01/msg00006.html>


> I tried setting !Table or !TabJoin to "foo as f1, foo as f2" but all 
> did not work well.  I finally patched DBIx::Database to handle table 
> aliases, and that seems to work fine.

looks like you need an svn account too :)

>
> On a related subject, there is a value '*MainTable' which always seems 
> to be the same as '*Table'.  I'm guessing that in joins it ought to be 
> the first table, and then in places where -label behavior is being 
> examined, it should use MainTable instead of Table.  But I'm just 
> guessing.  Of course if that's the case, then it ought to be set by 
> default to the first table in the !Table list, and it ought to be 
> possible to override it.

.#5 multiple links between tables patch (angus lees) . + 
http://www.ecos.de/~mailarc/embperl/2002-02/msg00058.html 
<http://www.ecos.de/%7Emailarc/embperl/2002-02/msg00058.html> . + NOT 
applied at present. It is not a complete fix.

If you read the link above, you will see that Gerald mentions that a 
complete solution would require a hefty rewrite.