Re: [Dbix-class] Prefetch problem
On Thu, Oct 2, 2008 at 04:14, Jesse Sheidlower [EMAIL PROTECTED] wrote: SELECT me.id, me.title, me.performer_id, me.number, me.capo, me.tuning, me.tab_id, me.audio_id, me.group_id, performer.id, performer.name, group.id, group.name FROM lesson me JOIN performer performer ON ( performer.id = me.performer_id ) JOIN lesson_group group ON ( group.id = me.group_id ) WHERE ( ( me.id = 35 ) ) ORDER BY me.title; This gives me the error: ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ON ( group.id = me.group_id ) WHERE ( ( me.id = 35 ) ) ORDER BY me.title' at line 4 try aliasing the table to grp instead of group, my guess is that group is a reserved word cheers m -- siggen.pl: Segmentation Fault ___ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
Re: [Dbix-class] Re: DBIx::Class::ResultSet::RecursiveUpdate - announcement and RFC
2008/10/2 Zbigniew Lukasiak [EMAIL PROTECTED]:
On Thu, Oct 2, 2008 at 2:40 AM, Matt S Trout [EMAIL PROTECTED] wrote:
On Wed, Oct 01, 2008 at 09:38:07AM +0200, Zbigniew Lukasiak wrote:
The example that I am mostly concerned with is:
$cd_rs-recursive_update( { title = 'New Title', artist = { name =
'New Name' } } )
Now when traversing the relation from cd to the artist I get the
artist resultset with the PK constrained in the -{cond}. There is
just one artist that the cd 'belongs_to' - and that artist should be
updated. But there is no PK passed in the parameters - so if we just
look at the parameters we would conclude that this would require a
-create call.
Ah, because the artist is about to be changed?
In that case you should create the artist separately and then assign it
I think, which again avoids the problem.
Perhaps I did not explain it enough - I want that call to result in an
update not a create. An update to the only artist that 'belongs_to'
the cd.
( /me steps into a minefield )
I would suggest that if it's an update, you should already have the
artist PK - keep ahold of it when you're initially getting the vales
from the DB.
Then, when you're doing the update, verify the PK hasn't changed (or
maybe allow it to be configured to allow rel ID changes).
I know FormFu doesn't do that, it can just follow the relationship
name, so you don't need a hidden field for the related PK - but I feel
it's more flexible to handle traversing the relationships ourselves,
rather than using a core DBIC recursive-update.
Carl
___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
[Dbix-class] prefetch in Example not needed
Hi, following a brief discussion in IRC and a quick test, I've come to the belief that prefetch in DBIx::Class::Manual::Example is not really needed. I've attached a patch to the documentation module and to the example script. I think that it could be useful because it really surprised me to see that prefetch there in the example, especially after reading the relevant prefetch documentation! Cheers, Flavio. PS: The patch has been formatted using git, but patch should grok it with no problem: patch -p1 0001-Removed-prefetch-from-example.patch 0001-Removed-prefetch-from-example.patch Description: Binary data ___ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
Re: [Dbix-class] install test failures
Zbigniew Lukasiak wrote: better load the latest svn version from: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/0.08/trunk I tried that but am seeing a problem - I'm not very familiar with building Perl distributions except from CPAN. It seems to have downloaded correctly but when I try to build it I see this: .../trunk$ perl Makefile.PL Can't locate inc/Module/Install.pm in @INC (@INC contains: /home/dhoworth/progs/modules /usr/lib/perl5/5.8.6/i586-linux-thread-multi /usr/lib/perl5/5.8.6 /usr/lib/perl5/site_perl/5.8.6/i586-linux-thread-multi /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.6/i586-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl .) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. And I'm not sure what I should do. Thanks, Dave ___ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
[Dbix-class] DBIx::Class and Red Hat perl bugs and performance redux
Red Hat carried a duff patch in their perl builds for RHEL5 and Fedora 5 though 7 (I think) for a period of time. The original patch was intended to deal with a real problem which affected certain combinations of bless/overload - see http://rt.perl.org/rt3/Public/Bug/Display.html?id=34925 However it had nasty effects in that a brute force search of blessed objects could happen under certain circumstances, leading to a exponential slow down for certain usage patterns. The Fedora issues were fixed in a Fedora 7 update in 2007. https://bugzilla.redhat.com/show_bug.cgi?id=196836 The issues in RHEL5 were finally fixed recently https://bugzilla.redhat.com/show_bug.cgi?id=379791 RHEL4 has never had this problem with a system perl, although the perl build for RHEL4 does have other issues (eg include paths and vendor/site ordering). DBIx::Class::StartupCheck - Both old and new perls trigger the startup check - as will any perl with the fixes to bless/overload bugs that is less than version 5.8.9. Other than doing performance checks, which would be prohibitively cpu intensive, I cannot think of a method for identifying this problem in the startup check code without hitting a lot of false positives. I see that this code is patched out in rpm distributions of DBIx::Class. I am wondering if the checks have now outlived their usefulness, at least as a by default option. Maybe they should be added to the test suite instead. DBIC Benchmarks --- The benchmark I am using is a simple pair of tables where set up so you can do a join-ed query on them. The resultset search parameters for each benchmark are tweaked to ensure the same SQL is generated, but they differ in what they do with the returned rows:- hashrefi_all: grabs the rows as a 2 level hash (prefetched) using DBIx::Class::ResultClass::HashRefInflator This is the we don't need no stinking objects version join_all: Only inflates the main RS objects - throws away the second level prefetch_all: Grabs and inflates all objects These benchmarks were run on an identical pair of VMs, the only difference being the installed perl version. The newer perl is fractionally slower on the hashref based benchmarks but significantly faster on the object based ones. Some more contrived examples show greater differences. Centos 5.2, perl perl-5.8.8-10.el5_0.2 (ie release version of perl) Benchmark: running hashrefi_all, join_all, prefetch_all for at least 30 CPU seconds... hashrefi_all: 31.9955 wallclock secs (31.74 usr + 0.08 sys = 31.82 CPU) @ 5.91/s (n=188) join_all: 34.6187 wallclock secs (34.40 usr + 0.04 sys = 34.44 CPU) @ 1.83/s (n=63) prefetch_all: 31.0027 wallclock secs (30.78 usr + 0.03 sys = 30.81 CPU) @ 1.20/s (n=37) Centos 5.2, perl perl-5.8.8-15.el5_2.1 (update version of perl) Benchmark: running hashrefi_all, join_all, prefetch_all for at least 30 CPU seconds... hashrefi_all: 32.3373 wallclock secs (30.40 usr + 1.12 sys = 31.52 CPU) @ 5.43/s (n=171) join_all: 32.5188 wallclock secs (30.22 usr + 1.30 sys = 31.52 CPU) @ 6.38/s (n=201) prefetch_all: 30.8614 wallclock secs (29.40 usr + 0.63 sys = 30.03 CPU) @ 3.33/s (n=100) Nigel. -- [ Nigel Metheringham [EMAIL PROTECTED] ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
Re: [Dbix-class] Prefetch problem
In theory you can set quoting on table and field names:
http://search.cpan.org/~ash/DBIx-Class-0.08010/lib/DBIx/Class/Manual/Cookbook.pod#Setting_quoting_for_the_generated_SQL.
In practice, though, that doesn't work 100% on DBs like Oracle and
it's hard to
spot all the reserved words so it may be easier on the sanity to use a table
prefix in your schema definition, like the following:
package Schema::User;
use base qw(DBIx::Class);
...
__PACKAGE__-table('az_user'); # reserved Oracle keyword 'user' is no good as
table name
then in caller:
my $rs = $self-schema-resultset('User')-find( 'foo' );
Regards, Peter
http://perl.dragonstaff.co.uk
Quoting Jesse Sheidlower [EMAIL PROTECTED]:
try aliasing the table to grp instead of group, my guess is that
group is a reserved word
Uh, yeah, that would be it.
___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
