Your test is incorrect: MySQL uses backticks instead of double quotes (as shown in the error message).

• compileInsertIgnore() should reuse compileInsert() instead of duplicating the code.
• I think it makes more sense for insertIgnore() to return the number of inserted rows (example).
• It would be possible to support SQL Server with the MERGE statement, but the syntax is more complex and would require insertIgnore() to have an additional parameter (example).

This is pretty cool, though I can't say I've personally reached for insert-ignore all that often. It assumes that on key conflict you are no longer wanting to update/refresh the values your inserting - this is often not what you want.

A more useful strategy is INSERT...ON DUPLICATE KEY UPDATE as suggested in this stackoverflow post: https://stackoverflow.com/a/548570/63523 -- now that is something I've wanted for a long time in Laravel. 😃

I use INSERT IGNORE in conjunction with UNIQUE constraints.

For example:

CREATE TABLE `test` (
	`id` INT(11) NOT NULL AUTO_INCREMENT,
	`foo` VARCHAR(50) NOT NULL DEFAULT '',
	`bar` VARCHAR(50) NOT NULL DEFAULT '',
	PRIMARY KEY (`id`),
	UNIQUE INDEX `foo_bar` (`foo`, `bar`)
);

INSERT IGNORE INTO test (foo, bar) VALUES ('A', 'A'), ('A', 'B'), ('A', 'C');
INSERT IGNORE INTO test (foo, bar) VALUES ('B', 'A'), ('A', 'B'), ('B', 'C');

No need to use INSERT...ON DUPLICATE KEY UPDATE -- but I do see the benefits in other situations.

Yeah it's useful in cases like that. Maybe the method could be called insertOrIgnore then that opens up the possibility of a insertOrUpdate method which uses the ON DUPLICATE KEY UPDATE strategy.

insertIgnore reads a bit strange to me

@garygreen The method should now read insertOrIgnore instead of insertIgnore. :)

@staudenmeir Thank you for the input.

• Reduced duplicated code
• insertOrIgnore now returns the number of inserted rows
• Added SQL Server support with help from your linked example

Resubmit without SQL Server support for this. It's the least used driver and I'm not adding parameters to the query builder just to support SQL Server.

@taylorotwell probably wasn't nesscary to close the PR, could of just asked the OP to amend. Jared has been very been responsive in suggestions.