Re: Abstracting SQL without Stored Procedures

Class::DBI

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Comment on Re: Abstracting SQL without Stored Procedures

Replies are listed 'Best First'.
â¢Re^2: Abstracting SQL without Stored Procedures by merlyn (Sage) on Sep 29, 2004 at 14:55 UTC
And/or SQL::Abstract and its close cousin Class::DBI::AbstractSearch. -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply]
Re^2: Abstracting SQL without Stored Procedures by radiantmatrix (Parson) on Sep 29, 2004 at 15:44 UTC
`Class::DBI` allows me to abstract from the POV of not needing to know much about SQL myself. However, one of the cited goals is to allow someone who knows SQL but not Perl to modify the SQL queries. I don't see how `Class::DBI` (or `SQL::Abstract`) can accomplish that. What am I missing? `require General::Disclaimer;` All code, unless otherwise noted, is untested "All it will give you though, are headaches after headaches as it misinterprets your instructions in the most innovative yet useless ways." - Maypole and I - Tales from the Frontier of a Relationship (by Corion)	[reply]
Re^3: Abstracting SQL without Stored Procedures by dragonchild (Archbishop) on Sep 29, 2004 at 15:48 UTC
Then, your Private:: idea is about the best you're going to get. SQL::Catalog might be of some service. Frankly, it might even be best to store your queries in the database itself and pre-load them when the app starts up. shrugs Being right, does not endow the right to be rude; politeness costs nothing. Being unknowing, is not the same as being stupid. Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence. Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better. I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]
Re^4: Abstracting SQL without Stored Procedures by mpeppler (Vicar) on Sep 30, 2004 at 01:55 UTC
Frankly, it might even be best to store your queries in the database itself and pre-load them when the app starts up. shrugs But if you do that - make sure that you actually keep the source to that information in operating system files, preferably under source control. Have the SQL specialist edit these files and load them to the data server as needed (and after thorough testing, of course). Michael	[reply]
Re^3: Abstracting SQL without Stored Procedures by Anonymous Monk on Sep 30, 2004 at 11:59 UTC
Use Class::DBI. It will save you enough time on the mundane create/update/search/retrieve logic that you can put more time into this customizable requirement. While it will set up defaults for standard create/update/delete/search and -to- relationships, you have the ability to change the SQL wherever you see fit. Class::DBI provides many ways to create your own constructors and custom SQL statements. Read Class::DBI -- Defining SQL Statements to learn more about this functionality.	[reply]


XP is just a number
	PerlMonks

Re: Abstracting SQL without Stored Procedures

This is an archived low-energy page for bots and other anonmyous visitors. Please sign up if you are a human and want to interact.