Shea --

There may be a legacy code situation or some political barriers, but
Peter's point is that you can modify both individual Result:: classes and
ResultSet:: classes to make your scripts much more powerful and flexible.
They're designed to work this way, which is why each Result class contains
two lines such as this:

# Created by DBIx::Class::Schema::Loader v0.07010 @ 2011-09-17 11:26:16

# DO NOT MODIFY THIS OR ANYTHING ABOVE! md5sum:npZZ70E+uwdbrUkjvsG7bA


You can add all kinds of handy conveniences BELOW that text including
__PACKAGE__->belongs_to(...)
__PACKAGE__->has_many(...)
has something => ( ... )

not to mention your own additional methods from scratch:

sub status {
  my $team = shift;
  while ( $team ) {
    return INACTIVE unless $team->active;
    $team = $team->parent;
  }
  return ACTIVE;
}

The Result classes can be pre-made from your database schema. The ResultSet
classes you get to conjure up entirely on your own, no limits!


On Mon, Apr 1, 2013 at 8:37 AM, Peter Rabbitson <rabbit+d...@rabbit.us>wrote:

> On Mon, Apr 01, 2013 at 09:07:51AM -0400, Shea Levy wrote:
> > On 04/01/2013 08:58 AM, Peter Rabbitson wrote:
> > >On Mon, Apr 01, 2013 at 08:54:55AM -0400, Shea Levy wrote:
> > >>Hi Peter,
> > >>
> > >>On 04/01/2013 08:46 AM, Peter Rabbitson wrote:
> > >>>On Mon, Apr 01, 2013 at 08:43:43AM -0400, Shea Levy wrote:
> > >>>>Hi all,
> > >>>>
> > >>>>In my db, a Project has many Jobs. I have a query on Projects where
> > >>>>I want to:
> > >>>>
> > >>>>1. Sort the jobs of each project by a particular column on the Jobs
> table
> > >>>>2. Only include jobs that satisfy some criterion, without excluding
> > >>>>    projects where no such jobs exist (i.e. add a condition to JOIN
> ON,
> > >>>>    not WHERE)
> > >>>>
> > >>>>Are either of these possible with a single search on Projects?
> > >>>>Currently we're breaking it up into two queries.
> > >>>Both are possible using usual syntax (and a custom-condition
> > >>>relationship) in a single query using the 0.08242 or greater (not yet
> > >>>released) version.
> > >>So something like (using Catalyst in my project):
> > >>
> > >>$c->model('DB::Projects')->search({ "jobs.hidden" => 0} {order_by =>
> > >>"jobs.name" })
> > >>
> > >Almost - jobs.hidden will produce a WHERE condition (what you do not
> > >want). Instead you want to declare a *new* relationship like this:
> > >
> > >
> https://github.com/dbsrgits/dbix-class/blob/master/t/lib/DBICTest/Schema/Artist.pm#L53
> >
> > Ah, I see. So I guess there's no way to do this without modifying
> > the schema?
>
> Not currently, however - what is so scary/undesirable about "modifying the
> schema" ?
>
> That is a real question - you are not the first to word things thusly. I
> need to figure out where the fear to add an extra definition is coming
> from.
>
> Cheers
>
>
> _______________________________________________
> 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/dbix-class@lists.scsys.co.uk
>



-- 
 Will Trillich :: 812.454.6431

“Grading takes away all the fun from failing. And a huge part of education
is about failure.”  -- Shimon Schocken
_______________________________________________
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/dbix-class@lists.scsys.co.uk

Reply via email to