Andrew Bramble (andrew.br...@omnilab.com.au)

On Thursday 06 July 2006 01:46, Matt S Trout wrote:
> Don't worry about this until the refactored query generator lands in the
> subselect branch, too many dragons.
Yup m found em. the comments about SQL::Abstract::Limit in there are quite
exciting.

> Try having => \"IFNULL(MIN(rights.permit,0))" etc.
Works for the simple case, in  a situation where those values are tested many 
times in 'having'  it turns messy very fast , plus I am unsure that a DBD 
would do any optimizing of the fact that

HAVING  ( IFNULL(MIN(rights.permit,0)) > 0 )   OR 
( IFNULL(MIN(rights.permit,0)) = 0  AND 
IFNULL(MIN(inherited_rights.permit,0)) = 1 )

uses the same invocation of functions on rights.permit twice  

Thanks for your suggestion , I'll await with eager anticipation the refactored
parts.

AB

Hello All,

I'm still playing around with DBIC but lovin it.
As pointed out to me today (thanks castaway) in #dbix-class , the 'as'
attributes to a resultset search have no bearing on the query used , only on
the returned objects which are give an accessor method described by the 'as'
attribute. I kicked myself when going back to read the BIG hint in the
ResultSet docs that say 'it will fail miserably' when used in this way.
Frustrating because the below search would be just great except for the fact
that the select columns cannot possible be referred to in the 'having'
clause. I had a crack at resolving this myself today in
DBIx::Class::Storage::DBI but it all fell down in _recurse_fields

the select produced by the below search looks like
SELECT id , IFNULL(MIN(rights.permit,0)),
IFNULL(MIN(inherited_rights.permit,0)) FROM ......

When it would be preferred to have
SELECT id AS id, IFNULL(MIN(rights.permit,0)) AS explicit_allow   .. .etc

I realise it is late and am starting to babble.
Would this type of behaviour be useful to anyone else ?

my $m= $s->resultset('Meta')->search( undef,
    {
            join=>[ qw/rights inherited_rights/ ],
            select=>[
                'id',
                { ifnull=>[ {min=>'rights.permit' },,0 ] } ,
                { ifnull=>[ {min=>'inherited_rights.permit'}, 0 ]  },
            ],
            as => [
                'id', 'explicit_allow', 'inherited_allow'
            ],
            order_by=>'explicit_allow',
            group_by=>[qw/me.id/],
            having=>{
                 explicit_allow=>1,
             }
    }
);

Many thanks for a great ORM

AB

I agree checksum would be better and more flexible.

Since the responsibility of parsing chunks of the raw request is given to
HTTP::Body by Catalyst, a plugin in Catalyst namespace would need to override
a method in HTTP::Body::Multipart and several within Catalyst  . Not sure how 
feasible this is.

As for a config param how about (YAML)

upload:
- checksum: Digest::MD5

Hello ,

Having used Catalyst for the last few months I was presented with a challenge;
make Catalyst generate an MD5 sum for each uploaded file in a request, for
files of (almost) arbitary length. Since MD5 summing a 640mb .iso is rather
time consuming, it makes sense to calculate the sum on the fly as the
incoming request is being processed.

It took me some time to track down the fact that HTTP::Body::MultiPart was
responsible for the writing of request data chunks to temporary files.
Attached is a first try at this which includes
patch HTTP::Body::Multipart to create a Digest::MD5 object and ->add chunks
of incoming data to it.
patch Catalyst::Request::Upload to add and accessor for 'md5'
patch &Catalyst::Engine::prepare_uploads to take the upload object(s) from
request->{_body}->upload  and create Catalyst::Request::Upload object 
including the 'md5' attribute.

I welcome comments about the sense and usefullness of this :)

AB _______________________________________________
List: [email protected: Cat...@lists.rawmode.org]
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Attachment: HTTP-Body-MultiPart.pm.digestmd5.patch

Agreed the nightly tests are rather the best 'documentation' of the widget set
- still there are some gotchas, like widgets that dont play well with others
- or widgets that require quirks mode (see the DTD of the tabContainer test)