ORMs du jour?
davehodg at gmail.com
Mon Oct 21 16:59:34 BST 2013
Does SQL::Abstract get you halfway?
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.
> 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
> 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.
More information about the london.pm