Adding quick_insert / quick_update to Dancer::Plugin::Database - design feedback requested
Hi all, I'm thinking of adding a couple of convenience features to Dancer::Plugin::Database, but I can't seem to decide on a clean interface design, and would appreciate any feedback. I very commonly find myself inserting/updating records in a database, so I'd like to provide quick_insert() and quick_update() keywords which would work something like: # Insert a new row into $table quick_insert($table, { field => 'value', field2 => 'value2' }); # Update the row where the id column is 42: quick_update($table, { id => 42 }, { field => 'newvalue' }); # Maybe also a way to delete rows quickly: quick_delete($table, { id => 42 }); The problem is mostly in supporting multiple database connections. I'm thinking either make quick_insert() and quick_update() accept a hashref of named parameters or a list of positional parameters, so in the simplest case you could use them as per above, and if you're using multiple connections, you could instead say e.g.: quick_insert({ connection => 'development', table => 'tablename', data => { field => 'value', ... }, }); quick_update({ connection => 'development', table => 'tablename', where => { id => 42 }, data => { field => 'new value' }, }); What do you think to that? I'm not particularly keen on it, but it would work. In both cases, you could supply a pre-written WHERE clause as a straight scalar, or a set of values as a hashef. (For most cases, you'd probably just use a hashref of e.g. { keycolumn => 'value' }). The other way I was considering was to allow an optional first param which would be the connection name, so e.g.: # Use the default database details: quick_insert('tablename', { field => 'value' ... }); # Use a different named connection: quick_insert('connectionname', 'tablename', { field => 'value' }); That would work, too, but changing the meaning of positional parameters feels wrong to me... Finally, I'm not sure whether to go with quick_insert / quick_update etc, or use names which make it clearer that they're database-related, like quick_db_update(), or database_quick_update(), or something similar. I'd appreciate anyone's thoughts. Cheers Dave P -- David Precious <davidp@preshweb.co.uk> (BIGPRESH) http://blog.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/identica www.lyricsbadger.co.uk "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)
Hello, David. Now with the help of your plugin the user is staying along only with dbh and to execute sql and retrive data user still need to make too many actions. It is super great that you are planning to add the new way to work with data. Before this your letter I've thought of how to make life with sql easier and started writing small module with my vision of how to do it (my vision is very simple, but not common - not to write sql requests in perl syntax, but to write them in sql). You mail inspired me to make my module more or less complete, and to upload it to github and cpan. Actually the module is not ready to work with Dancer (it has no mechanism to renew connection), but this is a first step. The module is avaliable at github: https://github.com/bessarabov/SQL-Easy (I've uploaded it to cpan, but some time should pass before it is avaliable). Concerning your question: I do agree that changing the meaning of positional parameters is not the right thing. From the other side writing every time huge hash is also not a good solution. Maybe you should not use procedures, but to use methods (and the object is the db connection)? 2010/12/3 David Precious <davidp@preshweb.co.uk>:
Hi all,
I'm thinking of adding a couple of convenience features to Dancer::Plugin::Database, but I can't seem to decide on a clean interface design, and would appreciate any feedback.
I very commonly find myself inserting/updating records in a database, so I'd like to provide quick_insert() and quick_update() keywords which would work something like:
# Insert a new row into $table quick_insert($table, { field => 'value', field2 => 'value2' });
# Update the row where the id column is 42: quick_update($table, { id => 42 }, { field => 'newvalue' });
# Maybe also a way to delete rows quickly: quick_delete($table, { id => 42 });
The problem is mostly in supporting multiple database connections.
I'm thinking either make quick_insert() and quick_update() accept a hashref of named parameters or a list of positional parameters, so in the simplest case you could use them as per above, and if you're using multiple connections, you could instead say e.g.:
quick_insert({ connection => 'development', table => 'tablename', data => { field => 'value', ... }, });
quick_update({ connection => 'development', table => 'tablename', where => { id => 42 }, data => { field => 'new value' }, });
What do you think to that? I'm not particularly keen on it, but it would work.
In both cases, you could supply a pre-written WHERE clause as a straight scalar, or a set of values as a hashef. (For most cases, you'd probably just use a hashref of e.g. { keycolumn => 'value' }).
The other way I was considering was to allow an optional first param which would be the connection name, so e.g.:
# Use the default database details: quick_insert('tablename', { field => 'value' ... });
# Use a different named connection: quick_insert('connectionname', 'tablename', { field => 'value' });
That would work, too, but changing the meaning of positional parameters feels wrong to me...
Finally, I'm not sure whether to go with quick_insert / quick_update etc, or use names which make it clearer that they're database-related, like quick_db_update(), or database_quick_update(), or something similar.
I'd appreciate anyone's thoughts.
Cheers
Dave P
-- David Precious <davidp@preshweb.co.uk> (BIGPRESH) http://blog.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/identica www.lyricsbadger.co.uk
"Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz) _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Saturday 04 December 2010 14:17:52 Иван Бессарабов wrote:
Now with the help of your plugin the user is staying along only with dbh and to execute sql and retrive data user still need to make too many actions. It is super great that you are planning to add the new way to work with data.
Indeed - Dancer makes many things so unbelievably easy, whilst still providing the flexibility to do whatever you want. I think D::P::Database needs to follow this mantra :)
Before this your letter I've thought of how to make life with sql easier and started writing small module with my vision of how to do it (my vision is very simple, but not common - not to write sql requests in perl syntax, but to write them in sql). You mail inspired me to make my module more or less complete, and to upload it to github and cpan. Actually the module is not ready to work with Dancer (it has no mechanism to renew connection), but this is a first step. The module is avaliable at github: https://github.com/bessarabov/SQL-Easy (I've uploaded it to cpan, but some time should pass before it is avaliable).
Interesting stuff. I do think it replicates a fair amount of stuff that could be done easily enough just with core DBI methods, though. For instance, from your examples, : my $posts_count = $se->return_one('select count(id) from posts'); print Dumper $posts_count; # will print $VAR1 = 42; Could be equally done with, e.g.: my ($posts_count) = $dbh->selectrow_array('select count(id) from posts'); Likewise,: my @a = $se->return_row("select dt_post, title from posts where id = ?", 1); Could be done with: my @a = $dbh->fetchrow_array('select ... where id = ?', undef, 1); (At least your modules avoids the need to pass undef (or an empty hashref, or something) to skip over the 2nd param, which always irritates me :) )
Concerning your question: I do agree that changing the meaning of positional parameters is not the right thing. From the other side writing every time huge hash is also not a good solution. Maybe you should not use procedures, but to use methods (and the object is the db connection)?
Yeah, that's another approach I considered; the more I think about it, the more I think this could be the correct answer. I think it would make sense to provide an option to enable/disable the extra stuff; with it disabled, the database() keyword would just return a DBI connection handle, as it does now. With it enabled, database() would instead return an object which subclasses DBI::db, but provides the extra methods. E.g. Dancer::Plugin::Database::Handle. That would make things much cleaner, as you could simply say: database->quick_insert($table_name, { field => 'value' }); and for a specific named database connection configuration, database('foodb')->quick_insert(...); That would seem to be sane, is entirely backwards-compatible (existing Dancer apps using D::P::Database wouldn't have the new option enabled, so would continue to receive a standard DBI::db handle just as they did before), and new apps which choose to make use of this behaviour get a handle that can do all the cool new stuff, but is a subclass of DBI::db, so still does all the traditional DBI stuff as you'd expect, too. I think I've convinced myself there, but would appreciate feedback from anyone else, too! (Starting to wish I'd done this before today's advent calendar post, so it could have been mentioned there!) Cheers Dave P -- David Precious <davidp@preshweb.co.uk> (bigpresh) http://blog.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/identica www.lyricsbadger.co.uk "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)
On Saturday, 4 December 2010, David Precious <davidp@preshweb.co.uk> wrote:
On Saturday 04 December 2010 14:17:52 Иван Бессарабов wrote:
Now with the help of your plugin the user is staying along only with dbh and to execute sql and retrive data user still need to make too many actions. It is super great that you are planning to add the new way to work with data.
Indeed - Dancer makes many things so unbelievably easy, whilst still providing the flexibility to do whatever you want. I think D::P::Database needs to follow this mantra :)
Before this your letter I've thought of how to make life with sql easier and started writing small module with my vision of how to do it (my vision is very simple, but not common - not to write sql requests in perl syntax, but to write them in sql). You mail inspired me to make my module more or less complete, and to upload it to github and cpan. Actually the module is not ready to work with Dancer (it has no mechanism to renew connection), but this is a first step. The module is avaliable at github: https://github.com/bessarabov/SQL-Easy (I've uploaded it to cpan, but some time should pass before it is avaliable).
Interesting stuff.
I do think it replicates a fair amount of stuff that could be done easily enough just with core DBI methods, though.
For instance, from your examples, :
my $posts_count = $se->return_one('select count(id) from posts'); print Dumper $posts_count; # will print $VAR1 = 42;
Could be equally done with, e.g.:
my ($posts_count) = $dbh->selectrow_array('select count(id) from posts');
Likewise,:
my @a = $se->return_row("select dt_post, title from posts where id = ?", 1);
Could be done with:
my @a = $dbh->fetchrow_array('select ... where id = ?', undef, 1);
(At least your modules avoids the need to pass undef (or an empty hashref, or something) to skip over the 2nd param, which always irritates me :) )
Concerning your question: I do agree that changing the meaning of positional parameters is not the right thing. From the other side writing every time huge hash is also not a good solution. Maybe you should not use procedures, but to use methods (and the object is the db connection)?
Yeah, that's another approach I considered; the more I think about it, the more I think this could be the correct answer.
I think it would make sense to provide an option to enable/disable the extra stuff; with it disabled, the database() keyword would just return a DBI connection handle, as it does now. With it enabled, database() would instead return an object which subclasses DBI::db, but provides the extra methods. E.g. Dancer::Plugin::Database::Handle.
Hi, I completely agree with the object oriented solution : I like it when a pluton has only few registered keyword, and return objects to do more stuff, like d::p::dbic. In your case I would recommend that you don't have an option to enable these features. You should always return a handle that inherits or behaves like DBI. That would reduce the number of options and still be backward compatible (. isa('DBI') and ->can() would work fine. If people misuse ref() instead, it's their fault ... )
That would make things much cleaner, as you could simply say:
database->quick_insert($table_name, { field => 'value' });
and for a specific named database connection configuration,
database('foodb')->quick_insert(...);
That would seem to be sane, is entirely backwards-compatible (existing Dancer apps using D::P::Database wouldn't have the new option enabled, so would continue to receive a standard DBI::db handle just as they did before), and new apps which choose to make use of this behaviour get a handle that can do all the cool new stuff, but is a subclass of DBI::db, so still does all the traditional DBI stuff as you'd expect, too.
I think I've convinced myself there, but would appreciate feedback from anyone else, too!
(Starting to wish I'd done this before today's advent calendar post, so it could have been mentioned there!)
Cheers
Dave P
-- David Precious <davidp@preshweb.co.uk> (bigpresh) http://blog.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/identica www.lyricsbadger.co.uk
"Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz) _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Hi all, Just a follow-up from the previous mail about this; I've now added the new quick_insert /quick_update / quick_delete features, and released 0.12_01 as a developer version to CPAN, to check that the tests all pass on a wide variety of systems. (I'm aware of test failures on Windows systems; this isn't a bug in D::P::Database, but I've added a workaround (just creating t/lib/{public,views/lib}) and tested this against a Windows VM and it passes tests and works correctly.) The new developer release can be found on CPAN: http://search.cpan.org/~bigpresh/Dancer-Plugin-Database-0.12_01 Basically, the way I've implemented the change is that the database() keyword, instead of returning a DBI connection handle (a DBI::db object), now returns a Dancer::Plugin::Database::Handle object. This is a subclass of DBI::db, so it is still a usable DBI database connection handle, and can be used in exactly the same ways it would have before, but adds a few features. These are documented in the POD for Dancer::Plugin::Database::Handle[0]. I'm aware of a couple of minor typos in the docs, which I've already fixed in my branch[1]. I'll wait to see some tester reports to check it passes tests, and would appreciate anyone who has time to try it out and provide feedback, but I'm confident it's stable and works. I'll release a new stable version with these changes soon; I'm as-yet undecided whether to release 0.13, or bump to 1.00 to signify that Dancer::Plugin::Database is mature and tested enough to rely on in production code. (I think some people see version numbers < 1 as a "watch out, this isn't ready for primetime!" warning.) [0] http://search.cpan.org/~bigpresh/Dancer-Plugin- Database-0.12_01/lib/Dancer/Plugin/Database/Handle.pm [1] https://github.com/bigpresh/Dancer-Plugin-Database/tree/extendedfeatures Cheers Dave P
Nice one, David ! I think it's a good idea to aim for 1.0, but maybe you can call it 0.90 (or 0.99 or whatnot), and give you few more weeks to wait for ay feedback ? just a thought dams On 8 December 2010 20:09, David Precious <davidp@preshweb.co.uk> wrote:
Hi all,
Just a follow-up from the previous mail about this; I've now added the new quick_insert /quick_update / quick_delete features, and released 0.12_01 as a developer version to CPAN, to check that the tests all pass on a wide variety of systems.
(I'm aware of test failures on Windows systems; this isn't a bug in D::P::Database, but I've added a workaround (just creating t/lib/{public,views/lib}) and tested this against a Windows VM and it passes tests and works correctly.)
The new developer release can be found on CPAN: http://search.cpan.org/~bigpresh/Dancer-Plugin-Database-0.12_01
Basically, the way I've implemented the change is that the database() keyword, instead of returning a DBI connection handle (a DBI::db object), now returns a Dancer::Plugin::Database::Handle object. This is a subclass of DBI::db, so it is still a usable DBI database connection handle, and can be used in exactly the same ways it would have before, but adds a few features.
These are documented in the POD for Dancer::Plugin::Database::Handle[0].
I'm aware of a couple of minor typos in the docs, which I've already fixed in my branch[1].
I'll wait to see some tester reports to check it passes tests, and would appreciate anyone who has time to try it out and provide feedback, but I'm confident it's stable and works.
I'll release a new stable version with these changes soon; I'm as-yet undecided whether to release 0.13, or bump to 1.00 to signify that Dancer::Plugin::Database is mature and tested enough to rely on in production code. (I think some people see version numbers < 1 as a "watch out, this isn't ready for primetime!" warning.)
[0] http://search.cpan.org/~bigpresh/Dancer-Plugin- Database-0.12_01/lib/Dancer/Plugin/Database/Handle.pm [1] https://github.com/bigpresh/Dancer-Plugin-Database/tree/extendedfeatures
Cheers
Dave P
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Beautiful, thanks David. ----- Original Message ----- From: "damien krotkine" <dkrotkine@gmail.com> To: "David Precious" <davidp@preshweb.co.uk> Cc: dancer-users@perldancer.org Sent: Thursday, 9 December, 2010 8:27:52 AM (GMT+1000) Auto-Detected Subject: Re: [Dancer-users] Adding quick_insert / quick_update to Dancer::Plugin::Database - done Nice one, David ! I think it's a good idea to aim for 1.0, but maybe you can call it 0.90 (or 0.99 or whatnot), and give you few more weeks to wait for ay feedback ? just a thought dams On 8 December 2010 20:09, David Precious < davidp@preshweb.co.uk > wrote: Hi all, Just a follow-up from the previous mail about this; I've now added the new quick_insert /quick_update / quick_delete features, and released 0.12_01 as a developer version to CPAN, to check that the tests all pass on a wide variety of systems. (I'm aware of test failures on Windows systems; this isn't a bug in D::P::Database, but I've added a workaround (just creating t/lib/{public,views/lib}) and tested this against a Windows VM and it passes tests and works correctly.) The new developer release can be found on CPAN: http://search.cpan.org/~bigpresh/Dancer-Plugin-Database-0.12_01 Basically, the way I've implemented the change is that the database() keyword, instead of returning a DBI connection handle (a DBI::db object), now returns a Dancer::Plugin::Database::Handle object. This is a subclass of DBI::db, so it is still a usable DBI database connection handle, and can be used in exactly the same ways it would have before, but adds a few features. These are documented in the POD for Dancer::Plugin::Database::Handle[0]. I'm aware of a couple of minor typos in the docs, which I've already fixed in my branch[1]. I'll wait to see some tester reports to check it passes tests, and would appreciate anyone who has time to try it out and provide feedback, but I'm confident it's stable and works. I'll release a new stable version with these changes soon; I'm as-yet undecided whether to release 0.13, or bump to 1.00 to signify that Dancer::Plugin::Database is mature and tested enough to rely on in production code. (I think some people see version numbers < 1 as a "watch out, this isn't ready for primetime!" warning.) [0] http://search.cpan.org/~bigpresh/Dancer-Plugin- Database-0.12_01/lib/Dancer/Plugin/Database/Handle.pm [1] https://github.com/bigpresh/Dancer-Plugin-Database/tree/extendedfeatures Cheers Dave P _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
I didn't know of the existence of ORLite. Did you see this? http://search.cpan.org/~adamk/ORLite-1.47/lib/ORLite.pm Adam has done most of the work. Why not just build on that? David Precious wrote:
Hi all,
Just a follow-up from the previous mail about this; I've now added the new quick_insert /quick_update / quick_delete features, and released 0.12_01 as a developer version to CPAN, to check that the tests all pass on a wide variety of systems.
(I'm aware of test failures on Windows systems; this isn't a bug in D::P::Database, but I've added a workaround (just creating t/lib/{public,views/lib}) and tested this against a Windows VM and it passes tests and works correctly.)
The new developer release can be found on CPAN: http://search.cpan.org/~bigpresh/Dancer-Plugin-Database-0.12_01
Basically, the way I've implemented the change is that the database() keyword, instead of returning a DBI connection handle (a DBI::db object), now returns a Dancer::Plugin::Database::Handle object. This is a subclass of DBI::db, so it is still a usable DBI database connection handle, and can be used in exactly the same ways it would have before, but adds a few features.
These are documented in the POD for Dancer::Plugin::Database::Handle[0].
I'm aware of a couple of minor typos in the docs, which I've already fixed in my branch[1].
I'll wait to see some tester reports to check it passes tests, and would appreciate anyone who has time to try it out and provide feedback, but I'm confident it's stable and works.
I'll release a new stable version with these changes soon; I'm as-yet undecided whether to release 0.13, or bump to 1.00 to signify that Dancer::Plugin::Database is mature and tested enough to rely on in production code. (I think some people see version numbers< 1 as a "watch out, this isn't ready for primetime!" warning.)
[0] http://search.cpan.org/~bigpresh/Dancer-Plugin- Database-0.12_01/lib/Dancer/Plugin/Database/Handle.pm [1] https://github.com/bigpresh/Dancer-Plugin-Database/tree/extendedfeatures
Cheers
Dave P
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
-- Puneet Kishor http://punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Fellow http://creativecommons.org/about/people/fellows#puneetkishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu --------------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science ===========================================================================
On Thursday 09 December 2010 14:00:28 Puneet Kishor wrote:
I didn't know of the existence of ORLite. Did you see this?
http://search.cpan.org/~adamk/ORLite-1.47/lib/ORLite.pm
Adam has done most of the work. Why not just build on that?
That looks to be an entirely different beast; it's an SQLite-centered lightweight ORM, rather than a standard DBI handle with added magic. It appears to be very much designed for use with SQLite, rather than with any database engine which DBI can be used with (which is, of course, pretty much any slightly-popular database, including MySQL, PostgreSQL, Oracle, SQLite...). Dancer::Plugin::Database is intended for people like me who want to use DBI, but would like a few convenience features, rather than going the ORM route, I don't think ORLite would be a good fit here. There's no reason there shouldn't be a Dancer::Plugin::ORLite, though ;) Cheers Dave P -- David Precious <davidp@preshweb.co.uk> http://blog.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/identica www.lyricsbadger.co.uk "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)
"sawyer x" <xsawyerx@gmail.com> wrote:
On Thu, Dec 9, 2010 at 4:27 PM, David Precious <davidp@preshweb.co.uk>wrote:
There's no reason there shouldn't be a Dancer::Plugin::ORLite, though ;)
Are you daring us? :)
Maybe :-) The rule seems to be that whenever someone mentions a plugin that doesn't exist, it exists on GitHub by the next day ;-) -- David Precious <davidp@preshweb.co.uk> Sent from my phone so please excuse brevity / poor quoting style etc
The only thing a plugin could add here is making it possible to configure the ORLite arguments in the Dancer configuration file. I don't how useful that will be, but maybe it will still get done, just to prove a point and prolong a myth. :) On Thu, Dec 9, 2010 at 11:58 PM, David Precious <davidp@preshweb.co.uk>wrote:
"sawyer x" <xsawyerx@gmail.com> wrote:
On Thu, Dec 9, 2010 at 4:27 PM, David Precious <davidp@preshweb.co.uk>wrote:
There's no reason there shouldn't be a Dancer::Plugin::ORLite, though ;)
Are you daring us? :)
Maybe :-)
The rule seems to be that whenever someone mentions a plugin that doesn't exist, it exists on GitHub by the next day ;-)
-- David Precious <davidp@preshweb.co.uk> Sent from my phone so please excuse brevity / poor quoting style etc
Hi David, what about an optional last parameter? Cheers, Flavio. On Fri, Dec 3, 2010 at 9:58 PM, David Precious <davidp@preshweb.co.uk>wrote:
Hi all,
I'm thinking of adding a couple of convenience features to Dancer::Plugin::Database, but I can't seem to decide on a clean interface design, and would appreciate any feedback.
I very commonly find myself inserting/updating records in a database, so I'd like to provide quick_insert() and quick_update() keywords which would work something like:
# Insert a new row into $table quick_insert($table, { field => 'value', field2 => 'value2' });
# Update the row where the id column is 42: quick_update($table, { id => 42 }, { field => 'newvalue' });
# Maybe also a way to delete rows quickly: quick_delete($table, { id => 42 });
The problem is mostly in supporting multiple database connections.
I'm thinking either make quick_insert() and quick_update() accept a hashref of named parameters or a list of positional parameters, so in the simplest case you could use them as per above, and if you're using multiple connections, you could instead say e.g.:
quick_insert({ connection => 'development', table => 'tablename', data => { field => 'value', ... }, });
quick_update({ connection => 'development', table => 'tablename', where => { id => 42 }, data => { field => 'new value' }, });
What do you think to that? I'm not particularly keen on it, but it would work.
In both cases, you could supply a pre-written WHERE clause as a straight scalar, or a set of values as a hashef. (For most cases, you'd probably just use a hashref of e.g. { keycolumn => 'value' }).
The other way I was considering was to allow an optional first param which would be the connection name, so e.g.:
# Use the default database details: quick_insert('tablename', { field => 'value' ... });
# Use a different named connection: quick_insert('connectionname', 'tablename', { field => 'value' });
That would work, too, but changing the meaning of positional parameters feels wrong to me...
Finally, I'm not sure whether to go with quick_insert / quick_update etc, or use names which make it clearer that they're database-related, like quick_db_update(), or database_quick_update(), or something similar.
I'd appreciate anyone's thoughts.
Cheers
Dave P
-- David Precious <davidp@preshweb.co.uk> (BIGPRESH) http://blog.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/identica www.lyricsbadger.co.uk
"Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz) _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
participants (7)
-
damien krotkine -
David Precious -
Flavio Poletti -
Matthew Vickers -
Puneet Kishor -
sawyer x -
Иван Бессарабов