From the DBIx::Class::Manual::Cookbook
--
Disconnecting cleanly
If you find yourself quitting an app with Control-C a lot during
development, you might like to put the following signal handler in your
main database class to make sure it disconnects cleanly:
$SIG{INT} = sub {
__PACKAGE__
for any sql dummies like me that come this way in future, this was the answer:
my $t = $c->model('Schema')->resultset('Phrases')->
count( { language_id => 3},
{ group_by => 'orig_id'} );
which works like this sql query :
select count (distinct orig_id) from phrases
I have noticed this same behavior using Class::DBI with Postgres.
-Original Message-
From: Toby Corkindale [mailto:[EMAIL PROTECTED]
Sent: Monday, January 08, 2007 9:52 AM
To: dbix-class@lists.rawmode.org
Subject: Re: [Dbix-class] Memory usage, something hanging on?
On Mon, Jan 08, 20
On Mon, Jan 08, 2007 at 04:59:20PM +, Matt S Trout wrote:
> On 8 Jan 2007, at 15:51, Adam Sjøgren wrote:
>
> > Hi.
> >
> >
> >In a Catalyst application I am working on, in which we use
> >DBIx::Class, server.pl just grew to use over 300MB ram, staying that
> >size from then on.
> >
[snip]
> >
On 08/01/07, Matt S Trout <[EMAIL PROTECTED]> wrote:
On 8 Jan 2007, at 15:51, Adam Sjøgren wrote:
> Hi.
>
>
> In a Catalyst application I am working on, in which we use
> DBIx::Class, server.pl just grew to use over 300MB ram, staying that
> size from then on.
>
> I've tried to replicate what
On 8 Jan 2007, at 15:51, Adam Sjøgren wrote:
Hi.
In a Catalyst application I am working on, in which we use
DBIx::Class, server.pl just grew to use over 300MB ram, staying that
size from then on.
I've tried to replicate what happens, and hope someone will comment on
whether this is expecte
Hi.
In a Catalyst application I am working on, in which we use
DBIx::Class, server.pl just grew to use over 300MB ram, staying that
size from then on.
I've tried to replicate what happens, and hope someone will comment on
whether this is expected behaviour, or something else.
To test this, I
It seems to me that a search with prefetch does not take into
consideration the extra attributes specified in the prefetched
relationships' attributes.
My device class defines its relationships like this:
__PACKAGE__->might_have(
"current_name_object",
"
On 1/8/07, Matt S Trout <[EMAIL PROTECTED]> wrote:
You don't. A lot of stuff happens at compile time that isn't
effectively repeatable. Your best bet is probably to do
touch lib/MyApp.pm
to force the -r reload to fire.
I think what he's saying is that even with "-r" sometimes the reload
doesn
On 8 Jan 2007, at 13:33, abhijith wrote:
You don't. A lot of stuff happens at compile time that isn't
effectively repeatable. Your best bet is probably to do
touch lib/MyApp.pm
to force the -r reload to fire.
Took your advice. But... touching MyApp.pm doesn't help solve the
problem.
We
> You don't. A lot of stuff happens at compile time that isn't
> effectively repeatable. Your best bet is probably to do
>
> touch lib/MyApp.pm
>
> to force the -r reload to fire.
Took your advice. But... touching MyApp.pm doesn't help solve the
problem.
We ll have to touch lib/MyApp/Schem
On 8 Jan 2007, at 07:46, abhijith wrote:
how do i reload the schema from the database without actually
having to
restart the server
You don't. A lot of stuff happens at compile time that isn't
effectively repeatable. Your best bet is probably to do
touch lib/MyApp.pm
to force the -r
12 matches
Mail list logo
