MarzQL wraps around the DBI module, allowing execution of SQL statments with any DBI-supported database on the fly in two lines or less! All that's required is the DBI module, DBD driver, and of course a database. A good understanding of SQL is needed as well. View the readme file for methods and instructions. You can find the download here: MarzQL page
This module is currently in production on the MP bot. Comments, suggestions, problems, hey youse!, and whatever else feel free to post. Whiners, complainers, insulters, and other ogres can withold useless ramblings unless you agree to pull your lower lip over your head and blow. Shout outs to the b-d team for some troubleshooting and pointers. _________________ Check out Botworld! A dev resource for things bot.
Downloads, articles, news, fourm and more.
http://botworld.marzopolis.com
Joined: 03 May 2006 Posts: 2292 Location: Colorado
Posted: Thu Feb 03, 2005 3:33 pm Post subject:
QUOTE(alienz @ Feb 2 2005, 10:03 PM)
MarzQL wraps around the DBI module, allowing execution of SQL statments with any DBI-supported database on the fly in two lines or less! All that's required is the DBI module, DBD driver, and of course a database. A good understanding of SQL is needed as well. View the readme file for methods and instructions. You can find the download here: MarzQL page
This module is currently in production on the MP bot. Comments, suggestions, problems, hey youse!, and whatever else feel free to post. Whiners, complainers, insulters, and other ogres can withold useless ramblings unless you agree to pull your lower lip over your head and blow. Shout outs to the b-d team for some troubleshooting and pointers.
This seems pointless. The only thing your module does is call
Code:
<br /> my $sth = $this->{'dbh'}->prepare("$sql");<br /> $sth->execute || die "\n\nErr executing SQL!\n\n$this->{'dbh'}->errstr";<br />
For every method you have. They are all identical. Why not use DBI's ->do method?
Code:
<br />mh $dbh = .....;<br />$dbh->do("DELETE * FROM table");<br />
_________________ Eric256
Proud previous owner and current admin of Bot-depot.com
The point is you don't have to know anything about DBI except the handle format. You can just use the module to send the SQL and it does the rest. I didn't expect everyone to like it anyway. Sorry it's not any fancier.
MarzQL lets you do this:
Code:
my $db = new MarzQL();<br />$db->dbh("handle");<br />$db->select("SELECT * FROM table");
I realize you could achieve the same thing with DBI, this just simplifies it some. I was originally only using this for myself because it replaced a subroutine that evaluated each SQL statement. The module elminiated the evaluation, made the process object oriented, and I didn't have to write the DBI code into the program's code. It also makes it easier for less experienced Perl coders to use DBI because the DBI specific code is transparent.
Also when debugging is turned on, it will show you alot of info about what's going on. It includes performance profiling too, so that you can see how DBI performed during the life of the app. _________________ Check out Botworld! A dev resource for things bot.
Downloads, articles, news, fourm and more.
http://botworld.marzopolis.com
I might, but the submission process is lengthy. _________________ Check out Botworld! A dev resource for things bot.
Downloads, articles, news, fourm and more.
http://botworld.marzopolis.com
LMAO ...yes it was a play on SQL _________________ Check out Botworld! A dev resource for things bot.
Downloads, articles, news, fourm and more.
http://botworld.marzopolis.com
Joined: 03 May 2006 Posts: 2292 Location: Colorado
Posted: Thu Feb 03, 2005 4:56 pm Post subject:
QUOTE(alienz @ Feb 3 2005, 07:40 AM)
The point is you don't have to know anything about DBI except the handle format. You can just use the module to send the SQL and it does the rest. I didn't expect everyone to like it anyway. Sorry it's not any fancier.
MarzQL lets you do this:
Code:
my $db = new MarzQL();<br />$db->dbh("handle");<br />$db->select("SELECT * FROM table");
I realize you could achieve the same thing with DBI, this just simplifies it some. I was originally only using this for myself because it replaced a subroutine that evaluated each SQL statement. The module elminiated the evaluation, made the process object oriented, and I didn't have to write the DBI code into the program's code. It also makes it easier for less experienced Perl coders to use DBI because the DBI specific code is transparent.
That still doesn't explain any benifit to using it. All the methods literaly wrap a single DBI method. In some cases it won't even work as expected because your selects are not returning anything. If you want to work with databases and not use SQL or DBI then I suggest exploring the DBIx namespace on cpan. It has lots of modules that let your write database code without knowing how to use DBI.
I don't mean to say your module is bad, I just don't see it adding anything except creating a whole bunch of methods that all do the same thing. _________________ Eric256
Proud previous owner and current admin of Bot-depot.com
In some cases it won't even work as expected because your selects are not returning anything.
I don't mean to say your module is bad, I just don't see it adding anything except creating a whole bunch of methods that all do the same thing.
The select does return data. It's all documented in the readme, I simply didn't assign the select to an array in the example. And none of the methods do the same thing. And, I don't take it as you saying it's bad...I know it's nothing spectacular, it's my first one LOL _________________ Check out Botworld! A dev resource for things bot.
Downloads, articles, news, fourm and more.
http://botworld.marzopolis.com
The only change is the name of the sub. There is no advantage to doing this over just calling ->do on the DBH. Now instead of a single ->do method you have a ton of methods. If you are planning on doing something more in there in the future then cool. Otherwise it is just adding more methods that all do one thing, execute a SQL command. DBI has that built in with ->do.
Now if the insert method just took a table name, and then the row of data to insert and created the SQL for you then that would be cool.
A note about the code. Since all those methods are identical you could have one method do that, and all the others call that specific method.
Also if you are going to wrap DBI you should provide a means for arguments to be passed to the execute so that place holders can still be used. You don't want to teach new people not to use place holders.
BTW I like the general idea. Well i like what I see as the general idea, wrapping DBI calls with good error handling. That added to being able to see where it is called from and what SQL was actualy passed could be very valuable. _________________ Eric256
Proud previous owner and current admin of Bot-depot.com
The only change is the name of the sub. There is no advantage to doing this over just calling ->do on the DBH. Now instead of a single ->do method you have a ton of methods. Otherwise it is just adding more methods that all do one thing, execute a SQL command. DBI has that built in with ->do. A note about the code. Since all those methods are identical you could have one method do that, and all the others call that specific method.
I didn't realize the ->do would execute any statement. That would've changed the way I did it in the beginning. My mistake. <_< That's something to consider for future revision.
Quote:
If you are planning on doing something more in there in the future then cool.
And I did have an eye toward maybe doing more in the future there.
Quote:
Now if the insert method just took a table name, and then the row of data to insert and created the SQL for you then that would be cool.
I agree, that would be cool..and easily done too.
Quote:
Also if you are going to wrap DBI you should provide a means for arguments to be passed to the execute so that place holders can still be used. You don't want to teach new people not to use place holders.
I did think about this, but since you can do an insert and enter any values you want, I didn't think placeholders were needed. Some drivers don't support placeholders either.
Quote:
BTW I like the general idea. Well i like what I see as the general idea, wrapping DBI calls with good error handling. That added to being able to see where it is called from and what SQL was actualy passed could be very valuable.
Thanks! _________________ Check out Botworld! A dev resource for things bot.
Downloads, articles, news, fourm and more.
http://botworld.marzopolis.com
Already working on a new version incorporating some of your suggestions. I've added ->do , and insert will create the SQL statement by getting the table, fields, and values. You'll be able to do the method a few different ways depending on whether your values are variables or hardcoded into the statement. A sample:
Thanks for the feedback. _________________ Check out Botworld! A dev resource for things bot.
Downloads, articles, news, fourm and more.
http://botworld.marzopolis.com
You should think about passing in a hash, where the keys are the field names and the values are the field values. This is how I do that with my Database module:
Joined: 03 May 2006 Posts: 2292 Location: Colorado
Posted: Thu Feb 03, 2005 10:01 pm Post subject:
Actualy DBI supports the placeholders and quotes the values for you in cases where the driver does not. So DBI + placeholders is a good thing regardless of what driver you are using.
"but since you can do an insert and enter any values you want,"
That is the problem. What if you accidently got a bad value in your insert? This is called SQL injection and can be very very bad. Using placeholders protects agiants it because it will quote/escape the incomming value in such a way that it can't be used to insert SQL. _________________ Eric256
Proud previous owner and current admin of Bot-depot.com
Ok, but wouldn't injection only be bad if say, someone else could put them in? The way I currently use it, only the values I code into it are passed...there is nearly nothing that a user could inject. Generally if something doesn't match up, such as the wrong data type, etc it'll die gracefully.
I like that idea mojave, but how do you get it to tell the keys are the fields and which is the values?
Like for example if my insert takes the table, fields and names as separate arguments and creates the sql...how would it take the hash and separate fields/values? _________________ Check out Botworld! A dev resource for things bot.
Downloads, articles, news, fourm and more.
http://botworld.marzopolis.com
User Control Panel
Posted: Thu Feb 03, 2005 5:05 pm Post subject: 