Thanks.
I was going by the one example in the documentation
my $sql = Fey::SQL->new_insert();
# INSERT INTO Part
# (part_id, name, quantity)
# VALUES
# (?, ?, ?)
$sql->insert()->into($Part);
my $ph = Fey::Placeholder->new();
$sql->values( part_id => $ph,
name => $ph,
quantity => $ph,
);
print $sql->sql($dbh);
where I assume $Part is a table object.
The example sql is how I think about it, and I assumed that the Fey values() method combined the column list (part_id, name, quantity) with the values (?,?,?) clause.
So if the example in the documentation were changed to use column objects in the into() method I would have gotten it wrong. But then the syntax seems redundant to use column names in the into() method and again in the values() method.
If using the column objects in the into clause one might be able to just pass $ph in the values clause OR automatically generate the values clause with placeholders. In other words
$sql->insert()->into($part_id, $name, $quantity)
would generate the sql
INSERT INTO Part (part_id, name, quantity) VALUES (?,?,?)
If one called $sql->values(val1, val2, val3) it would instead generate
INSERT INTO Part (part_id, name, quantity) VALUES (val1, val2, val3)
Except that it's generally good practice to use the DBI placeholders and call execute() with the bind parameters so quoting or escaping is correct.
Thanks for the clarification.
-John
On Dec 14, 2010, at 3:01 PM, Dave Rolsky via RT wrote:
Show quoted text> <URL:
https://rt.cpan.org/Ticket/Display.html?id=63881 >
>
> Yes, you're right that column order is important. I'm not sure what I
> was thinking.
>
> However, looking more closely I realize that order is preserved. If you
> want a specific column order in the INTO clause you need to pass the
> columns in that order. If you simply pass a table object then internally
> the code calls $table->columns. The order of columns() is currently
> random, which is the real bug.
