DBIx::Class is great if you: - Generate it automatically from your _well designed (haha)_ DB with DBIx::Class::Schema::Loader
- Don't try to extend it too much. It _can_ become very messy. - Wrap your business model _around_ it. (like in https://github.com/jeteve/jcom/blob/master/JCOM-BM/lib/JCOM/BM/DBICWrapper.pm ). J. On 21 October 2013 17:07, Joel Bernstein <j...@fysh.org> wrote: > 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 <daveh...@gmail.com> wrote: > >> Does SQL::Abstract get you halfway? >> >> Avoid Tangram. >> >> >> On Mon, Oct 21, 2013 at 3:47 PM, Dirk Koopman <d...@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 >> > >> > >> >> -- Jerome Eteve +44(0)7738864546 http://www.eteve.net/