[Dbix-class] doing a search

[John Napiorkowski]

--- Octavian Rasnita <orasnita at gmail.com> wrote:

> From: "Nilson Santos Figueiredo Junior"
> <acid06 at gmail.com>
> 
> > You've probably set up a relationship called
> "id_role" and thus it's
> > getting called instead of the "id_role" field
> accessor. Try changing
> > the name of this relationship.
> 
> Oh yes, that was the problem.
> 
> Can you tell me in which cases are the relations
> "belongs_to" needed?
> I have seen that the authorization works even if I
> comment them out. I think 
> they are not required for the authorization, and I
> don't know if I should 
> keep them or not.

The relations are just there to make it easy to
express how objects in your physical model are
related.  You could skip them if you wanted, although
that you would lose a lot of the power of the system.

The idea here is that if you are smart in creating
your tables so that they can express your business
rules and constraints properly than you will have code
that makes a lot more sense.  You can do stuff like:

my $Employee = $Employees->find({id=>1});

$Employee->promote;
$Employee->fire;
$Employee->is_on_vacation;

OR

my $Programmers = $Employees->Programmers();

OR (for relationships, assume there is an Employee
table and a Computer table with a can_have
relationship, that is an employee can have a computer)

if( $Employee->has_computer )
{
   my $Computer = $Employee->Computer();

   if( $Computer->operating_system eq "Windows" )
   {
      print "${Employee->fullname} needs operating
system upgrade right away!";
   }
}

and so forth.  So this can be much more than just a
way to avoid SQL to get at table attributes (although
that in and of itself can be very helpful).  By using
this to express relationships and rules you can make
your code more reusable and more clear.  So the answer
to the question "Which relationships are needed" is
depending on your domain rules.  At a minimum I
recommend that you properly express all the
constraints and relationships inside the physical
database model (assuming that was done correctly in
the first place) and then you want to express your
business rules.  There is some discussion about the
best way to do this, which most people feeling it is
ideal to have a seperate business logic object that
consumes a DBIC object, although if your needs are
simple enough you can just put everything into the
class file.

I know it's a lot to take in at once, cut yourself
some slack and realize it will take you some time. 
The more you work on this the more you will understand
why this was made this way.  

take it easy,
John


> 
> Thank you for help.
> 
> Octavian
> 
> 
> _______________________________________________
> List:
>
http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
> Wiki: http://dbix-class.shadowcatsystems.co.uk/
> IRC: irc.perl.org#dbix-class
> SVN:
>
http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
> Searchable Archive:
>
http://www.mail-archive.com/dbix-class@lists.rawmode.org/
> 



 
____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index