|Do you know where your variables are?|
Re: Perl ORM comparison (Class::DBI vs. DBIx::Class vs. Rose::DB::Object)by siracusa (Friar)
|on Aug 04, 2008 at 00:34 UTC||Need Help??|
Only supports pg, MySQL, SQLite, and Informix for the moment. Oracle support is there but apparently not full.
FWIW, Oracle support is basically complete. Pretty much everything should work, but the Oracle code has not been tested nearly as much as the other drivers so I left the waffling in the documentation for now.
Column inflation/deflation is not customizable
It sure is. Check out the inflate/deflate column triggers.
No client-side triggers. (but cascading deletes and loads are supported.)
There are client-side column triggers. Triggers on load(), save(), etc. can be added with the usual method wrappers (override method, call SUPER::) or using any generic subroutine trigger/wrapper module on CPAN.
Executing arbitrary SQL is really hard to get at (need to use DBH directly) and there is no bridge between that SQL and the ORM. (is this true?)There are a few methods where you can supply complete raw SQL queries and get back ORM objects (e.g., get_objects_from_sql()), but yes, it's rare (and kind of contrary to the purose of an ORM, after all). Literal SQL snippets can be used almost anywhere, however, using the common (among Perl ORMs) convention of passing a reference to a scalar.
No distinction for "primary/essential/other/all" column kinds except for primary key. (Maybe a performance issue for large columns. However, apparently, Rose::DB::Object is otherwise the best performer.)
The concept exists, just in a different form. Columns may be marked as "lazy," in which case they are not automatically loaded when an object is load()ed, but rather are loaded on demand.
No support for UUID columns.
I'm not sure what you mean by that, but if I'm close, you should be able to do that kind of thing using the existing column defaults mechanism combined with something like Scalar::Defer.