laziness, impatience, and hubris | |
PerlMonks |
Re: Search for ORM with Multi-Table-Object Supportby Your Mother (Archbishop) |
on May 02, 2012 at 20:14 UTC ( [id://968530]=note: print w/replies, xml ) | Need Help?? |
Why did you reject DBIC? It's probably what you want. The following is a brief tour of its power. Multi-Table-Mapping-ObjectsPseudo-code which assumes some manual set-up in the schema files (many to many relationships are not discoverable and the example would require overload on the role class to work as shown)–
DBIC has notions of the column, the resultset, the table, the record, the connection, the relationships, and more. Many ORMs are record oriented and get ugly/stuck easily since it's all a ball of mud around a row. DBIC handles this really nicely. Lazy-Loading (Single Columns as well as groups of columns)
Agregation FunctionsThe get_column above is an example. DBIx::Class::ResultSetColumn has more, like–
All sorts of relationshipsAlso see the amazing DBIx::Class::Tree::Mobius for an inner-relationship hybrid of nested intervals and materialized paths. Flexible ways to query data from databaseChained resultsets are everything good in the world. You essentially build up complementary named fragments and make your code compact, syntactical, and fun. For example (assumes you wrote the resultset code, which is easy, to do it)–
Multi-Database-SupportNo. Yes. What? DBIC supports pretty much everything DBI does. It does not support joining across DBs. You can certainly have a schema instance for each DB exchanging information at the Perl level. More readingUpdate: missing adverbly.
In Section
Seekers of Perl Wisdom
|
|