note Anonymous Monk Well, let's see. "We do our best to maintain full backwards compatibility for published APIs, since DBIx::Class is used in production in many organisations, and even backwards incompatible changes to non-published APIs will be fixed if they're reported and doing so doesn't cost the codebase anything." versus "BUT the author states in the documentation that it may change any time!" No. I don't. Please correct. "No support for in-memory-only objects (just like Class::DBI" Wrong. ->new gives you a memory-only object, which you insert by calling $obj->insert. We also provide a CDBI-ish create() that is a shortcut for new+insert. "No client-side triggers." That's because Class::Trigger style stuff costs you every time you check it for an object without a trigger. What we do instead is make sure things are factored out enough that methods are trivial to override - for e.g. <pre> sub insert { my ( $self, @args ) = @_; $self->next::method(@args); $self->cds->new({})->fill_from_artist($self)->insert; return $self; } </pre> is next to no more typing than setting an after_insert trigger in Class::DBI. "Executing arbitrary SQL is more cumbersome (You have to set up a ResultSource for this. Note that executing arbitrary SQL may be considered by some as bad practise for an ORM.)" Well, except you can pass arbitrary chunks for pretty much anything - the 'select' attr lets you control the select clause, the 'from' attr the from clause, and scalar references in the where clause are treated as literal SQL. And, of course, if you want to just get the $dbh, you can just get the $dbh - or run $schema->storage->dbh_do(sub { my $dbh = shift; ... }) at which point you'll get our retry/reconnect logic for free as well. So I think "you have to" is basically wrong, at least. I wonder if you need a new, fresh node (and maybe I could poke jcs, the RDBO author, to correct any similar mistakes in your stuff for his work) -- mst (DBIx::Class project founder) 700283 700283 19