ORMs du jour?

Joel Bernstein joel at fysh.org
Mon Oct 21 16:54:25 BST 2013

I suspect you should be looking at DBIx::Class, and something like

Many of your assumptions seem invalid. I'm not sure what foibles you
expect, but "generating SQL queries on the fly" is exactly what DBIC does,
with the benefit of those query abstractions being orthogonal, composable,
testable etc.


On 21 October 2013 17:47, Dirk Koopman <djk at tobit.co.uk> wrote:

> On 21/10/13 15:33, Abigail wrote:
>> On Mon, Oct 21, 2013 at 02:37:52PM +0100, Dirk Koopman wrote:
>>> Any recommendations for an ORM? I am looking for something simple rather
>>> than lots of bells and whistles.
>> My recommendation for ORMs: don't.
>> http://blogs.tedneward.com/**2006/06/26/The+Vietnam+Of+**
>> Computer+Science.aspx<http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx>
> and also
> On 21/10/13 15:31, Jason Clifford wrote:> On 2013-10-21 14:37, Dirk
> Koopman wrote:
> > What is your requirement - ie the use case?
> >
> >
> Traditionally what I have done is abstracted all the SQL queries that I
> want to use into a "class" (read: package) and call those "methods" usually
> as functions (returning arrays of data). The reason for this is that my
> programs' SQL queries cover a database's contents very sparsely but
> specifically and, compared to the size of said database, in a very limited
> way. An ORM would not have gained me a huge amount of time or enough other
> "goodness" to make it worth the effort learning that ORM's foibles.
> I now find myself needing to provide something that could, in the limit,
> replicate some C programs that are able create arbitrarily complex
> "reports", that will be punted into a Mojo webserver for onward service to
> a punter. The punters in question will not be using SQL :-).
> The SQL required will cover a much larger range of the tables (as well as
> quantities of data) in the database, even for the first cut which will
> simply webify some existing excel "reports". But the webification only
> amounts to providing that data in JSON and punting it down a websocket. (Oh
> and the original screen of course, but that is out of scope for this
> discussion).
> It has to be said that my instinct would be with Abigail. But the very
> fact that I am asking the question means that I recognise that some OOish
> view of this database might be useful.
> Obviously, if this system that I am starting now ends up where I think it
> will, I could simply generate SQL queries on the fly and hide them in some
> real (generated) classes and carry on like that. It is very likely that
> this, in the first instance, also a reasonable possibility.
> The decision could turn either way at the moment.
> Dirk

More information about the london.pm mailing list