I thought this all felt a bit like "surely someone's done this before!" :)
Tho I feel any use of DBIx::Class would exist even under this level of interface - I nearly want html/TT coders to be able to call my methods, but certainly don't want them this close to the inner-workings of my models.
We're already heavily using MySQL, all old legacy code that's 10 years old, with no objects in sight! This is all new code I'm writing to refactor the old scripts.
| [reply] |
Not only has it been done before, it has been done much better than you will do it. If you were experimenting, I’d say, “Hells yeah, go for it and have fun!” But if this is really for work, “You are making a huge mistake and you are punishing the future developers who will hate you for it if they have any sense at all.”
DBIx::Class (just for one, and there are other excellent ORMs in Perl) works out of the gate with all the common DBDs, it has oodles of support tools for auto-generation of code, introspection, inflation, versioning, helpers, constrainers, dumping, deployment, etc, and it comes with a community, a stable history, and a test suite that concludes as of this moment with–
Files=251, Tests=5141, 152 wallclock secs ( 2.20 usr 1.28 sys + 125.6
+3 cusr 13.35 csys = 142.46 CPU)
Result: PASS
If you can conjure 5,000 passing tests for your new code, I withdraw my objection.
| [reply]
[d/l] |
for (1..5000) {
is(do("SELECT $_"), $_);
}
Way faster than DBIx::Class's test suite too! ;)
| [reply]
[d/l] |
This is true, tho I would see DBIx::Class being used under my layer I am writing (see my later responses for other examples).
I'm also very aware that we'll soon move some of our data out of a database and over to some other storage engine, such as Solr.
If it was purely database modelling, I'd be using DBIx::Class in a shot, but my query is more about a layer above the db, a bit closer to the controller aspect of an MVC design, if you like.
| [reply] |