|There's more than one way to do things|
Relatively young code with a still changing interface
Actually DBIx::Class is almost 3 years old now and is being used heavily by a large number of systems in production, while it may not be "old" code, it is certainly "battle tested" code, I think that you have nothing to worry about there.
As for the stability of the interface, I also wouldn't worry about that either. Because it is being used so heavily in prod already, it is very unlikely that anything but the guts will ever change. And having just spent a whole week at OSCON with the author discussing the next version, I can safely say that you have nothing to worry about.
I am not sure that is true, you might want to ask on the mailing list. I would be shocked if no one had devised a way to use triggers through DBIx::Class
Executing aribtrary SQL is more cumbersome (You have to set up a ResultSource for this.)
Actually the ResultSorce is already set up for you, it is the object that DBIx::Class uses to connect with the DBI handle. You just have to dig to get at it. As for executing arbitrary SQL, yes it is a little trickier, but once you wrap your head around it it is not that bad. Sometimes doing things you probably shouldn't do (like execute arbitrary SQL within the context of an ORM) should be a little harder.
The search syntax is quite complex and cumbersome.
Yes, I will agree on that. For simple stuff it is not that bad, but complex stuff can get hairy. However, DBIx::Class is the project currently driving the effort to improve that with a new version of SQL::Abstract.
In reply to Re: Class::DBI vs. DBIx::Class comparison