Perl: the Markov chain saw | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
G'day SpaceCowboy, You have a lot of mistakes in your code. Here's a selection:
We all make typos but, with this many, you're quite likely to spend more time debugging than coding. Pay more attention to the code you're writing: don't make a rod for your back. "Any general wisdom here?" The following is intended to be very generic. There's not enough up-front information for me to provide working code. Adapt what I have here for your specific needs. I'd probably start with a front-end script that might look something like:
I don't know what you had in mind for "***import database credentials here"; perhaps Getopt::Long, a config file, or something else. I'll leave how you populate $database_credentials up to you. In a separate file (.../SpaceCowboy/Database/Module.pm), code SpaceCowboy::Database::Module which does all the work. Here's a rough example of what that might look like:
I've included a very basic new() method; however, you'll probably find one of the many frameworks available are easier to work with — Moo might be a good one to use here. See also: "perlintro: OO Perl" and perlootut. The database handle, $DBH, is lexically scoped such that only dbh() can access it directly. It is only ever set once. You'll need to look at the DBD::whatever documentation, for whatever database you intend to use, to find out the correct way to call DBI->connect(...). "how can I serialize the execution?" You could use flags for each of primary(), first(), etc. Set these to indicate which parts have completed successfully; do not rerun the flagged parts. You'll possibly need a reset() method, to turn these off, so that a fresh run from the start is possible. "Is it possible to write multiple statements like dbh->do("create temp schema", "insert table");" That may be dependent on the database you're using. You could write:
Be aware that might be problematic if you're also trying to flag the success of individual statements. Ask yourself why you think you'd need this. If you can't come up with a good reason, don't do it. — Ken In reply to Re: designing a program - your wisdom needed
by kcott
|
|