[2.0] Why does Evolutions split the SQL before executing it?

[Wilhansen Li]

In Play 1.x, the Evolutions script reads the SQL, splits it by the
semicolon (i.e. ';') then applies it per statement. That is:
for (String sql : (evolution.applyUp ? evolution.sql_up :
evolution.sql_down).split(";")) {
if (StringUtils.isEmpty(sql.trim())) {
continue;
}
execute(sql);
}

This causes problems if the SQL has entity names with semicolons or if
the SQL contains stored procedures as documented in this ticket:
https://play.lighthouseapp.com/projects/57987/tickets/997-play-evolutions-splits-indiscriminately-by-quoting-problem
The fix is simply to shove the entire SQL up the java.sql.Statement
and execute it.

I thought this has been fixed in Play 2.0 but upon seeing this code:
https://github.com/playframework/Play20/blob/master/framework/src/play/src/main/scala/play/api/db/evolutions/Evolutions.scala#L207-210
I guess the old behavior has been kept.

I find no reason for splitting the SQL. It's not like
java.sql.Statement cannot accept multi-statement SQL, neither does the
code split it per-statement to keep the line number for error
reporting. Is there anything I missed that gives justification to the
current behavior?

Regards,
Wil

[Guillaume Bort]

> It's not like
java.sql.Statement cannot accept multi-statement SQL

Are you sure of that? Perhaps it depends of the Driver.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>

--
Guillaume Bort

[Wilhansen Li]

On Jan 15, 3:47 am, Guillaume Bort <guillaume.b...@gmail.com> wrote:
> > It's not like
>
> java.sql.Statement cannot accept multi-statement SQL
>
> Are you sure of that? Perhaps it depends of the Driver.
>
>

Oh snap. You're right.... MAAAN, this is gonna be a pain to do
properly. Thanks for pointing that out.