John and we could persuade the database server to apply those updates to the target table? This is in fact entirely possible in many database systems. It is relatively straightforward to populate a table with multiple rows with just one query or at least, far fewer queries than the number of rows desired.
So, given a list of updates to apply we could effect them using the following steps: But now the number of statements is no longer directly dependent on the number of rows requiring updates. Even if we wanted to update a thousand rows with different values, we could still do it with four statements.
The code required to implement the above logic is sufficiently fiddly that we would probably not want to have to repeat it. So we could think in terms of creating a re-usable module which would implement that logic. This is the intention of DBIx:: The input to the function would be a list of updates which the caller desires to be made. Each update should contain two things: An indication of which row should be updated New values for one or more fields Going back to our first example: MultiRow, we would write: Each element is a two-element array.
MultiRow is structured so that approaches which are generic across different SQL databases are expressed in a base class, and approaches which only work for specific SQL databases are expressed in a subclass. An object of the relevant class is instantiated when the call is made, and control then passed to the implementation relevant to the database in use.
If there is no database-specific subclass for the database in use, then DBIx:: MultiRow will just use the base class which implements approaches that should work for any SQL database. At the time of writing, the only database-specific subclass is for PostgreSQL. There are a few more details worth mentioning.