ORMs du jour?

[Joel Bernstein]

It gets you halfway in the sense of all the pain of an ORM solution with
none of the gain, yes.


On 21 October 2013 17:59, Dave Hodgkinson <davehodg at gmail.com> wrote:

> Does SQL::Abstract get you halfway?
>
> Avoid Tangram.
>
>
> On Mon, Oct 21, 2013 at 3:47 PM, 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
> >
> >
>
>