Re: looking for a OR-mapper for Moose
by stvn (Monsignor) on Apr 14, 2009 at 00:26 UTC
|
DBIx::Class is not (yet) written in Moose, but many people have used Moose and DBIx::Class together quite successfully. And if your looking for maturity and stability in an ORM, DBIx::Class is the right choice (no offense to Fey::ORM, but as the author says in the docs, it is still kinda new).
| [reply] |
Re: looking for a OR-mapper for Moose
by Sartak (Hermit) on Apr 13, 2009 at 21:48 UTC
|
Fey is a very Moosey SQL generator, upon which Fey::ORM is built. It's written by Dave Rolsky, a core Moose developer, who writes bulletproof code.
That said, its documentation does warn you that "This is still very new software, and APIs may change in future releases without notice. You have been warned."
I don't know what your requirements are, but Fey is definitely Moosey and is probably solid enough to use.
| [reply] |
|
"... who writes bulletproof code"
Well, someone was posting on Perlmonks while high, clearly.
| [reply] |
|
| [reply] |
|
I calls em like I sees em.
| [reply] |
|
| [reply] |
|
| [reply] |
Re: looking for a OR-mapper for Moose
by jrockway (Acolyte) on Apr 13, 2009 at 21:55 UTC
|
You should take a look at KiokuDB. It is probably what you want, and although it is rather new, it is in production in some pretty important apps.
It is an object database rather than an ORM, which means that you can't edit the database from outside of the Perl world. If you just want to query the objects with SQL, though, you can use GIN to index the necessary attributes in your app. (The docs describe this in detail, it is a common thing to do.)
This probably sounds "different" than what you are used to, but KiokuDB has made our apps a lot cleaner than a relational database + DBIC, and in many cases, more efficient. You will also have a variety of choices for backends; you can use Oracle if you want, but you can also use Berkeley DB, CouchDB, Amazon SimpleDB, and so on... without changing your app's code.
| [reply] |
Re: looking for a OR-mapper for Moose
by Corion (Patriarch) on Apr 13, 2009 at 21:14 UTC
|
As this will be a mission-critical system I would prefer something solid and proven over something cool.
And you're using Moose?
I'm unaware of a DBI backend for MooseX::Storage, but it shouldn't be hard to write one. You "just" have to think about how you want to implement the storage of traits, as a separate table or within the per-class-table. Adding hand-written SQL will be hard, as always.
| [reply] |
|
Moose has been around for three years. It's being used in production by several companies with household names, as well as perhaps hundreds of smaller organizations and countless end-users.
Its theoretical foundation goes back probably nearly thirty years.
Is there anything in particular that makes you question Moose's provenness and solidity?
| [reply] |
|
Being developped for three years means nothing - Perl6 has been in development for almost 10 years now.
I'm not sure what you mean by "household names", but I don't think that I can ask my mother about any Moose-using-Perl company and get a set of answers that contains any of the names you seem to have in mind. I guess that we're both aware of many things whose theoretical foundations go back far longer than 30 years and that still are not a good idea. I question Mooses provenness because it's simply too young and while using it, I've seen that it's nice conceptually but doesn't buy me much over plain objects. I see it much like the Inside-Out fad that produced a slew of bad prerequisites and little else. Of course it's always questionable to use a fancy new technology for a mission critical part.
| [reply] |
|