Short answer: I'm almost positive that
keys and
values
will always return hash entries in the same order, until
the hash is modified. If you're really concerned about it,
you can do something like this:
my($l_tablename, %l_data) = @_;
my(@fields, @values);
push(@fields, $_) && push(@values, $1_data{$_})
for(keys %1_data);
my($1_prepare);
{
local $" = ','; # eliminate join statements
$1_prepare = qq(
INSERT INTO $1_tablename (@fields)
VALUES (@values)
);
}
Long answer:
- The first literal character in a variable can't be a
numerical value. So "1_" will have to go! =)
- In your original code, you assign a hash to a shift
statement. This won't work because you'll only get the
first value from the list you pass. The assignment arrow
operator => acts the same as a comma in
a list, and lists flatten. So something like this will
happen:
@list = ('arg1', ('field1' => 'value1', 'field2' => 'value2'));
# above same as:
@list = ('arg1', 'field1', 'value1', 'field2', 'value2');
$table = shift(@list); # 'arg1'
%fields = shift(@list); # 'field1'
The last statement, in order to put all the remaining
values from @list into %fields
should read: %fields = @list;
- Writing a function to prepare generic insert statements
is generally a bad idea. This is just asking for people to
call your function with invalid table names, field names,
and data types. If the database itself changes, it becomes
more difficult to fix the code because you have to track
down every place where this subroutine is being called.
There's probably a better way to do what you're trying
to do. Writing an insert subroutine for each table in the
database that allows new records might be a better
solution. If you are really ambitious, you can even write
an OO wrapper for each table, with select, insert, update,
and delete methods. Then you can write things like:
my $person = new MyDB::Person(4);
$person->update(name => 'John B.');
instead of
&update('person', { pk => 4, name => 'John B.' });
...or whatever. Just a few thoughts for you to mull over. {g}