ORMs du jour?
Any recommendations for an ORM? I am looking for something simple rather than lots of bells and whistles.
Re: ORMs du jour?
DBIx::Class. On 21 October 2013 15:37, Dirk Koopman d...@tobit.co.uk wrote: Any recommendations for an ORM? I am looking for something simple rather than lots of bells and whistles.
Re: ORMs du jour?
Any recommendations for an ORM? I am looking for something simple rather than lots of bells and whistles. Wrong question. You don't want something simple, you want something that you can easily google for help when you don't understand something, or ask for help when you don't get something. You want something reliable. In Perl, that's DBIx::Class. Mark. -- Mark Fowler http://www.twoshortplanks.com/
Re: ORMs du jour?
Rose DB http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object/Tutorial.pod On Mon, Oct 21, 2013 at 5:42 PM, Joel Bernstein j...@fysh.org wrote: DBIx::Class. On 21 October 2013 15:37, Dirk Koopman d...@tobit.co.uk wrote: Any recommendations for an ORM? I am looking for something simple rather than lots of bells and whistles. -- Best regards, Pavel Vlasov Please consider the environment before printing this email.
Re: ORMs du jour?
On Mon, Oct 21, 2013 at 03:42:31PM +0200, Joel Bernstein wrote: On 21 October 2013 15:37, Dirk Koopman d...@tobit.co.uk wrote: Any recommendations for an ORM? I am looking for something simple rather than lots of bells and whistles. DBIx::Class. Despite DBIx::Class having bells, whistles, cymbals, duck calls, a consort of viols, a smoke machine (available in blue, red and bright orange) and a small dancing bear called Eric - it is still the correct answer. The basics are dead simple, and unlike most simple tools, it can actually do the more complex stuff that you'll find you need later. There's even a reasonably smooth and gentle learning curve to get to them. -- David Cantrell | London Perl Mongers Deputy Chief Heretic If you can read this, thank a teacher. If you're reading it in English, thank Chaucer.
Re: ORMs du jour?
On 21/10/13 14:42, Joel Bernstein wrote: DBIx::Class. On 21 October 2013 15:37, Dirk Koopman d...@tobit.co.uk wrote: Any recommendations for an ORM? I am looking for something simple rather than lots of bells and whistles. That does seem like the default choice. I should perhaps have added that I need to query an ingres database rather closely. I have successfully used DBI for this in the past, but the time has now come to do something (considerably) more complex.
Re: ORMs du jour?
On 2013-10-21 14:37, Dirk Koopman wrote: Any recommendations for an ORM? I am looking for something simple rather than lots of bells and whistles. What is your requirement - ie the use case?
Re: ORMs du jour?
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 Abigail
Re: ORMs du jour?
On Mon, Oct 21, 2013 at 7:33 AM, Abigail abig...@abigail.be 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. Or at the very least, have an ORM be something your data model uses for convenience, not have it *be* your data model.
Re: ORMs du jour?
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 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
Re: ORMs du jour?
I suspect you should be looking at DBIx::Class, and something like https://metacpan.org/module/Catalyst::Controller::DBIC::API 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. /joel On 21 October 2013 17:47, 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.aspxhttp://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
Re: ORMs du jour?
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.aspxhttp://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
Re: ORMs du jour?
On 21/10/13 16:54, Joel Bernstein wrote: I suspect you should be looking at DBIx::Class, and something like https://metacpan.org/module/Catalyst::Controller::DBIC::API 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. Catalyst is not an option. Sorry. All software has foibles, as well as a learning curve. Even mine.
Re: ORMs du jour?
On 21 Oct 2013, at 15:33, Abigail abig...@abigail.be wrote: [...] My recommendation for ORMs: don't. http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx I've only skimmed that article, but it seems to make the fairly common assumption that OO means Java-style OO, and because ORMs fit badly with his notion of OO and how it might be mapped to a relational model, all ORMs are bad. Much of the blog post can be basically summed up by the languages I use are too verbose, error-prone and inflexible that an ORM does not win me anything[0]. Which is something I quite agree with. Perl's is *not* like those languages, and DBIx::Class is not like those half-jobbed messes that Ted has apparently been burned by in the past. The people who built DBIx::Class have done a really excellent job of building something rather special. [0] Ted's LinkedIn page tells me he's basically a .NET programmer who has also touched Java and C++.
Re: ORMs du jour?
Oh, it doesn't have to be Catalyst, the point was (and surely this was clear if you read the module i linked to...) that you should use something that reflects the DBIC schema and wraps it in a CRUD HTTP API automatically. As an example of the kind of thing you get for free once you've specified your data domain properly. Out of interest why are you ruling out what is arguably the standard choice for Perl webapp development, while still defining what tools to use? /joel On 21 October 2013 18:18, Dirk Koopman d...@tobit.co.uk wrote: On 21/10/13 16:54, Joel Bernstein wrote: I suspect you should be looking at DBIx::Class, and something like https://metacpan.org/module/**Catalyst::Controller::DBIC::**APIhttps://metacpan.org/module/Catalyst::Controller::DBIC::API 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. Catalyst is not an option. Sorry. All software has foibles, as well as a learning curve. Even mine.
Re: ORMs du jour?
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/
Re: ORMs du jour?
On Mon, Oct 21, 2013 at 04:47:05PM +0100, Dirk Koopman 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 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. I see you want an abstraction layer. Abstraction layers can be good [1]. Your code also wants to work with objects. Nothing against that either. You also seem to have data. But ORM stands for three things. You haven't told us about the relations, nor how you intend to map your objects to relations. Quite important is, how are you building it? Do you start with your data, laid out in tables and relations, and now want an object hierarchy to represent this [2]? Or do you have a class hierarchy already, and now you want a mapping to relations [3]? [1] Do note can. For obvious reasons, abstraction layers tend to be generic. Unfortunally, specially when dealing with large datasets, generic can come with a significant cost. Sometimes, code is better off bypassing any generic layer, having a specific SQL query that work just then and there, with the current database layout. [2] I've yet to see an ORM implementation done this way that doesn't break encapsulation and abstraction even before any code is written. As soon as you type in vi NameOfTable.pm, your database layout is dictate your code layout, and *poof* goes any abstraction and encapsulation. [3] Got a shiny inheritance tree? Perhaps even multiple inheritance? You also want a normalized database? Good luck! Abigail
Re: ORMs du jour?
On 21 Oct 2013, at 17:19, Peter Corlett ab...@cabal.org.uk wrote: On 21 Oct 2013, at 15:33, Abigail abig...@abigail.be wrote: [...] My recommendation for ORMs: don't. http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx I've only skimmed that article, but it seems to make the fairly common assumption that OO means Java-style OO, and because ORMs fit badly with his notion of OO and how it might be mapped to a relational model, all ORMs are bad. Much of the blog post can be basically summed up by the languages I use are too verbose, error-prone and inflexible that an ORM does not win me anything[0]. Which is something I quite agree with. Perl's is *not* like those languages, and DBIx::Class is not like those half-jobbed messes that Ted has apparently been burned by in the past. The people who built DBIx::Class have done a really excellent job of building something rather special. [0] Ted's LinkedIn page tells me he's basically a .NET programmer who has also touched Java and C++. Seconded. Also, the article's sixth recommendation sounds awfully like how DBIx::Class works: Integration of relational concepts into frameworks. Developers simply accept that this problem is solvable, but only with a change of perspective. Instead of relying on language or library designers to solve this problem, developers take a different view of objects that is more relational in nature, building domain frameworks that are more directly built around relational constructs. For example, instead of creating a Person class that holds its instance data directly in fields inside the object, developers create a Person class that holds its instance data in a RowSet (Java) or DataSet (C#) instance, which can be assembled with other RowSets/DataSets into an easy-to-ship block of data for update against the database, or unpacked from the database into the individual objects. At $WORK I was initially against adopting an ORM - mostly because we were adding Dancer and Moose to our code base already - but it's been invaluable. At its most basic it just gives you arbitrary classes based on your database tables, so you can use them as a glorified replacement for $dbh-fetchrow_hashref; but when you add the ability to automatically prefetch table contents, you can end up with very easy optimisation of your SQL queries without having to delve into the guts of the database. Sam -- Website: http://www.illuminated.co.uk/
Re: ORMs du jour?
On Tue, Oct 22, 2013 at 12:19 AM, Peter Corlett ab...@cabal.org.uk wrote: Much of the blog post can be basically summed up by the languages I use are too verbose, error-prone and inflexible that an ORM does not win me anything[0]. Which is something I quite agree with. In case anyone was considering actually reading it, this is a pretty inaccurate summary IMO. There's a small section on verbosity but considering Active Record is referenced it's by far not the most pressing concern the author covers by a long way. It's a long article and does capture pretty thoroughly the impedance mismatches and gotchas with trying to bridge OO/RDBMS. One of the best I've read. Even if you're fully committed to ORMs, and there are many, many great reasons and fully justifiable scenarios to go with one in our current environment (prevalence of built-from-scratch, lightweight webapps), knowing the potential pitfalls down the road is important. Paul
Re: ORMs du jour?
On 21/10/13 17:27, Jérôme Étévé wrote: DBIx::Class is great if you: - Generate it automatically from your _well designed (haha)_ DB with DBIx::Class::Schema::Loader Noted. And I laughed so much. Well designed? It is, at least (over) mature and not likely to change enough to be a particular problem. - Don't try to extend it too much. It _can_ become very messy. Not likely to do that. I tend to wrap, rather than extend, modules that I take from CPAN. That way I stand a chance to remain in some form of control when (data) structure changes under my feet. - Wrap your business model _around_ it. (like in https://github.com/jeteve/jcom/blob/master/JCOM-BM/lib/JCOM/BM/DBICWrapper.pm ). I will look at that.
