Dopo aver bestemmiato come un satanista, forse ne sono uscito. Finalmente.

Gli schemi che si mangia DBIx::Class sono di questo genere (ho tagliato la definizione delle colonne, perché irrilevante):

package Tr0n3::Schema::Main::Result::Thoughts;
[]
use base ‘DBIx::Class’;

__PACKAGE__->load_components("InflateColumn::DateTime", "TimeStamp", "EncodedColumn", "Core");
__PACKAGE__->table("thoughts");
__PACKAGE__->add_columns(
  "id",  { [] },
  "title",  { [] },
  "body",  { [] },
  "create_time",  { [] },
  "last_modif",  { [] },
  "author_id",  { [] },
);
__PACKAGE__->set_primary_key("id");
__PACKAGE__->add_unique_constraint("thought_pkey", ["id"]);
__PACKAGE__->belongs_to(
  "author_id",   "Tr0n3::Schema::Main::Result::Authors",   { id => "author_id" },
);
1;

e

package Tr0n3::Schema::Main::Result::Authors;
[]
use base ‘DBIx::Class’;

__PACKAGE__->load_components("InflateColumn::DateTime", "TimeStamp", "EncodedColumn", "Core");
__PACKAGE__->table("authors");
__PACKAGE__->add_columns(
  "id",  { [] },
  "nick",  { [] },
  "password",  { [] },
  "mail",  { [] },
  "create_time",   { [] },
  "last_login",  { [] },
);
__PACKAGE__->set_primary_key("id");
__PACKAGE__->add_unique_constraint("authors_pkey", ["id"]);
__PACKAGE__->has_many(
  "links",   "Tr0n3::Schema::Main::Result::Links",   { "foreign.author_id" => "self.id" },
);
__PACKAGE__->has_many(   "thoughts",   "Tr0n3::Schema::Main::Result::Thoughts",   { "foreign.author_id" => "self.id" },
);
1;

Per fare una join con DBIC ci si appoggia alle relazioni:

Authors->has_many( "thoughts", "Tr0n3::Schema::Main::Result::Thoughts", { "foreign.author_id" => "self.id" }, );

Thoughts->belongs_to( "author_id", "Tr0n3::Schema::Main::Result::Authors",   { id => "author_id" }, );

has_many crea una relazione “uno a molti”, e ha come argomenti: il nome dell’accessor, il nome della classe che rappresenta la tabella, un hashref con la reference (a cosa punta la foreign key).
In pratica lo schema Authors è in connessione uno a molti con Thoughs (per un Author ci possono essere molti Thoughts) , la relazione si chiama thoughts e vi si accede attraverso l’accessor thoughts, che punta allo schema Main::Result::Thoughts, secondo la relazione author_id (nella tabella thoughts) – id (nella tabella author).

In maniera analoga, lo schema Thoughts ha una relazione belongs_to con nome author_id, che punta allo schema Authors e che lega l’id in Authors con l’author_id di Thoughts.

Grazie a queste relazioni esplicitate nello schema, è possibile creare delle join in DBIx::Class:

my $thoughts_rs = $schema->resultset(‘Thoughts’);
my @join_TA = $thoughts_rs->search( { }, { join => ‘author_id’, columns => [ qw/ id title create_time author_id.nick / ], } );

Questa join parte dal ResultSet di Thoughts e senza filtri fa un JOIN con author attraverso l’accessor author_id.
L’SQL risultante è:

SELECT me.id, me.title, me.create_time, author_id.nick FROM thoughts me JOIN authors author_id ON author_id.id = me.author_id

(Il prefisso “me” – inserito da DBIC – indica la tabella a sinistra del join.)



1 Comment to “DBIx::Class – Le join”


  1. SIMOTRONE WEB PAGE » Blog Archive » DBIC, le join (2) — 13 February 2010 @ 7:15 am

    [...] DBIC, le join (2) Feb13 13 February 2010, Simotrone @ 7:11 am Come già accennato, le relazioni fra gli schemi (che rappresentano tabelle) avvengono grazie alla configurazione di [...]



Write a comment


You need tologin.

    
SIMOTRONE WEB PAGE is based on WordPress platform, RSS tech , RSS comments design by Gx3.