All the Perl that's Practical to Extract and Report
use Perl Log In
Ovid (2709)
(email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)
Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.
Are you using your objects, or are they using you?
Want to have fun sometime? Take a moderately complex system, open up one of your tests which instantiates an object and put the following line in your test just after you've instantiated an object:
$DB::single = 1;
That sets a breakpoint so that when you run the test under the debugger (perl -d t/some_test.t), you can type 'c' and the code will run until it hits that line. So imagine this:
#!/usr/bin/env perl
use strict;
use warnings;
use Test::Most 'no_plan';
use My::ORM::Customer; # ORM classes are great for this
use My::Test::Fixtures;
My::Test::Fixtures->load('customers');
my $customer = My::ORM::Customer->find({ id => 1 });
$DB::single = 1;
Now assuming that your code has stopped just after the $customer object has been instantiated, type this in the debugger and be amazed:
m $customer
In the debugger, the 'm' command tells you which methods are available on an object and which classes they're from. I did this for a simple object we instantiate. It's for our ORM and it represents a table with 8 fields, two of which are only for auditing. 255 methods were listed. Two hundred and fifty-five. They are defined across twenty-seven classes. And frankly, I'm not convinced that this list is complete, but that's the debugger for you.
Just some food for thought.
:-)
--Larry Wall in <11091@jpl-devvax.JPL.NASA.GOV>
Oh don't tease us... (Score:1)
... and how many of those were from UNIVERSAL:: ? :)
Re: (Score:2)
The full list of classes involved:
Change ORM ! (Score:1)
Well, if 255 methods/27 classes are too much for your taste, change ORM!
DBIx::DataModel [cpan.org] will only cost you about 50 methods in 3 classes (the exact number depends on how many relationships there are between this table and other tables).
(sorry, DBIC folks, I couldn't resist ...)
Re: (Score:2)
Well, I doubt I could push that through at work, but I suspect that I'd be inclined to go the SQL dictionary route. Still, just glancing at it, DBIx::DataModel looks interesting.
Re: (Score:1)
No no, no SQL dictionary, you want to look at Fey.
Re: (Score:2)
Ah, that looks lovely! And yes, better than a dictionary.
Re: (Score:1)
It is lovely! I have been using it for a while and it has worked out every bit as well as I had hoped for. Sometimes I had to change the shape of my queries a little to accommodate it, but I have yet to run into a wall due to the fundamental design. There were stumbling blocks in cases where I ran into corners that Dave hadn’t built out yet – f.ex. when I first started with it, it failed if you tried to join against a table alias, which I needed for my tag (as in “folksonomy”) joins.
Re: (Score:1)
package Forum::Model::User; use Forum::Model::Schema; use Fey::ORM::Table; has_table( Forum::Model::Schema->Schema()->table('User') );It could be just:package Forum::Model::User; use base Forum::Model::Schema; has_table( 'User' )I am acustomed to the DBIC way of having a normal Schema object that keeps the connectRe: (Score:1)
I’m talking only about Fey::SQL, not Fey::ORM. I don’t use Fey::ORM at all.
But do to take up your concerns with Dave – he’s a reasonable guy.
Re: (Score:1)
Re: (Score:1)
Ah. Well, I am happy to remain blissfully unaware of these issues and to stick with Fey::SQL. :-)