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