All the Perl that's Practical to Extract and Report

Query Catalogs for DBI Programs

gnat on 2003-03-28T12:38:22

Wow. Why didn't I try this sooner? I've hated jamming SQL into my program and never knowing what I'd have to change when I realized I'd need another field in the database. All I'm doing now is creating a hash of placeholder-filled SQL statements with keys like "add_person" "find_address", and when I connect to the database I prepare a statement handle for each piece of SQL and store the statement handles in another hash. Then when I need to do something with SQL, I bind and execute.

I just split a new table off, realizing my model was wrong. It was so simple! Thankyouthankyouthankyou use.perl for putting this seed into my head (or rather, thank you TPC speaker whose name I've forgotten who gave a talk on this in years past, and thank you use.perl for freshening the synapses).

--Nat

Tim Allwine

jjohn on 2003-03-28T13:13:22

I seems to me that Tim Allwine introduced me to that technique while I was at ORA. He's got some fancy-dan SQL skillz. Mad props!

Lazy

warming on 2003-03-28T16:27:17

I have been using that technique a while now. I've actually combined it with Autoload - for added pleasure.

The result is so far is DBIx::Lazy (CVS), which I'm using many a place.

I feel that I still need to look through a lot of DBIx:: modules before considering adding it to CPAN.
But you get the point. Anyway I like it! :)

Works for XML too

pemungkah on 2003-03-31T16:05:35

I've been doing someting similar with our current project - we're interfacing to a web services client for data searches. Most of it is what I call "stereotyped" XML - the form doesn't really change, you just plug in different values and sections.

The responses are also pretty stereotyped, so it's pretty easy to make up catalogs of XPath expressions to extract the data you really want. Development time dropped dramatically, and it's really simple to follow any changes made to the web service spec.