There are several micros (I'm sure you know) but I love the micro, micro approach of Peta. I'll admit that up until recently, I've always setup my own classes with data myself. Looking back on projects, it actually hasn't been that bad. These are medium sized applications and, yes, setting up properties is super annoying and can take a while but, in retrospect, it hasn't cost me that much really, I don't see how I could save more than a few hours with an ORM and I have 100% control over my database interactions, code separation, complete knowledge about exactly what it is doing, and a fast application.
I like Peta because it's the smallest most minimal ORM I've found. I can grasp most of what it's doing after little work with it and it's fast enough for me though I'm definitely not pushing it too hard.
I've fallen head over heels for (Perl's) DBIx::Class and it's ability to "prefetch" joined data[1]. In short, it will populate the top level objects, as well as the items they join to from a single query (yes the DB will have to send duplicate info). I find it really convenient.
Recently I've wondered what other ORMs support this feature or something similar to it. Anyone care to comment?
It sounds like what you're referring to is something I know as eager loading[1]. Most good ORMS have this e.g. Django[2], NHibernate[3], Rails[4]. The 'select N+1' problem[5] is fairly common.
Ah, that's probably a much easier term to google. Part of the problem always seems to boil down to terminology. :) I figured it must be present in other ORMs, it seemed way to useful to not be pervasive.
It looks like select_related is the equivalent Django method to what I'm referring to in DBIx::Class, although prefetch_related (which you linked) looks superior in many respects. I'm fairly certain DBIx::Class allows a similar method to prefetch_related, but it may or may not be automatically done. I know it supports object caching, so it shouldn't be to hard to achieve in a few lines (but automatic is nice).
Interestingly, I don't see a way in Django to specify complex select fields to be included along with the default fields for a record. In a simple case that can be used to get a count of something, in complex cases it could be used to actually compute something on the DB to group and/or limit by (group by having). I'm probably just not familiar enough with QuerySets from this small bit of exposure to work it out.
NHibernate... That's a lot of code for something that should be simple. I imagine that's for explanatory reasons, and that much code isn't needed for most queries.
EF is a massive 'enterprise' codebase aimed predominately at SQL Server. If you don't need all the features ORMs like EF (or NH for that matter) offer (with all their associated config) then a micro-orm maybe better suited.
Dapper has been very useful at my current gig and more innovation in that space the better. Okay these micro-ORMs lack fundamentals like identity maps and caching but do you always need these features?
No, Dapper does not suck. I too have been using Dapper at our company recently and its been an incredible boon to our db performance and code readability.
Plus, if its good enough for the Stack Exchange team, then its plenty good enough for me.
On a more serious note, FluentData is a wheel reinvented, square. PetaPoco anyone?