Delete DSL with as got Syntax Error with MySQL

[wuranbo]

use DSL like this

delete.from(SavedSchedule as s).where.eq(s.ownerId, ids_str.toInt)

will generate the SQL

delete from SavedSchedule s where s.owner_id = 9;

got the ERROR:

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that  corresponds to your MySQL server version for the right syntax to use near 's where s.owner_id = 9' at line 1

Is it a MySQL SQL compatible bug?

scalikejdbc: "org.scalikejdbc" %% "scalikejdbc" % "2.3.4",
MySQL: 5.5.47

[jeffbondlink]

This is an old and existing issue with mysql, delete does not support table
aliases, so unless the as s is important for some reason, just write them
as delete.from(SavedSchedule).where.eq(column.ownerId, ids_str.toInt). Not
the use of column, there may be other ways, but that will work.

On Sat, Sep 24, 2016 at 11:46 AM, Wu Ranbo notifications@github.com wrote:

use DSL like this

delete.from(SavedSchedule as s).where.eq(s.ownerId, ids_str.toInt)

will generate the SQL

delete from SavedSchedule s where s.owner_id = 9;

got the ERROR:

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 's where s.owner_id = 9' at line 1

Is it a MySQL SQL compatible bug?

scalikejdbc: "org.scalikejdbc" %% "scalikejdbc" % "2.3.4",
MySQL: 5.5.47

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#567, or mute the
thread
https://github.com/notifications/unsubscribe-auth/APdcMzdApUE3oMH8getpcUjSiNIigK2iks5qtUXjgaJpZM4KFrBL
.

[seratch]

Indeed, it's a little bit confusing but you need to use #column instead for insert/update/delete SQLs instead. http://scalikejdbc.org/documentation/query-dsl.html#delete

[wuranbo]

@jeffbondlink @seratch thanks.
Just it's kind of easy to write wrong code, and not being checked in compiling time superised me much.
Dose we got some thinking to improve it? I saw the source code QueryBuilder is splited to C.R.U.D already, then we can mixin the diffrent Database as trait (or else) to solve this? just chat chat. ^_^

[seratch]

Introducing some kind of "marked" SQLSyntax may improve type safety of the APIs but it would bring backward incompatibility. It might be considerable in 3.0 (no plan yet though)

[wuranbo]

@seratch got it. Thx.