ORMs du jour?

[Jérôme Étévé]

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 <joel at 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 <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
>> >
>> >
>>
>>



-- 
Jerome Eteve
+44(0)7738864546
http://www.eteve.net/