Batchinlaga med tabell som har många kolumner med hjälp av Anorm

Jag väljer alternativ B. Jag är inte så bekant med BatchSql sedan sist jag kollade kör den bara en båtlast av frågor i sekvens, vilket är fruktansvärt långsamt. Jag skulle rekommendera att samla allt i en enda fråga. Det är lite tråkigare, men mycket snabbare att köra en enda fråga med tusen inlägg än tusen enstaka inlägg.

För enkelhetens skull, låt oss säga att du har Seq av

case class Test(val1: Int, val2: Option[Long], val3: Option[String])

Sedan kan du bygga din fråga så här:

val values: Seq[Test] = Seq(....)

/* Index your sequence for later, to map to inserts and parameters alike */
val indexedValues = values.zipWithIndex

/* Create the portion of the insert statement with placeholders, each with a unique index */
val rows = indexValues.map{ case (value, i) =>
    s"({val1_${i}}, {val2_${i}}, {val3_${i}})"
}.mkString(",")

/* Create the NamedParameters for each `value` in the sequence, each with their unique index in the token, and flatten them together */
val parameters = indexedValues.flatMap{ case(value, i) =>
    Seq(
        NamedParameter(s"val1_${i}" -> value.val1),
        NamedParameter(s"val2_${i}" -> value.val2),
        NamedParameter(s"val3_${i}" -> value.val3)
    ) 
}

/* Execute the insert statement, applying the aggregated parameters */
SQL("INSERT INTO table1 (col1, col2, col3) VALUES " + rows)
    .on(parameters: _ *)
    .executeInsert()

Anmärkningar:

Du måste kontrollera att values är inte tom innan du fortsätter, eftersom den skulle generera en ogiltig SQL-sats om den var det.

Beroende på hur många rader och kolumner du infogar, kommer så småningom tokentolkarna som skapade den förberedda satsen att sakta ner från den stora mängden tokens att analysera (och strängstorleken). Jag har märkt detta efter några hundra rader med flera kolumner. Detta kan mildras något. Tack vare att Scala är ett starkt skrivet språk, Int och Long utgör inget hot för SQL-injektion. Du kan förbereda dina SQL-satser med hjälp av stränginterpolation/konkatenering för just dessa kolumner och binda de osäkra kolumnerna med NamedParameter i vanliga fall. Det skulle minska antalet tokens som behöver analyseras.