search

sqlanywhere / sqlany-django

Django driver for SAP Sybase SQL Anywhere
Other
17 stars 25 forks source link

Gracefully decline to connect to versions < 12 #1

Closed jamesrusso closed 9 years ago

jamesrusso commented 10 years ago

I have an application which uses SQLAnywhere 10. I am getting error on connection due to:

cursor.execute("SET OPTION PUBLIC.reserved_keywords='LIMIT'")

However, after that error I am able to interact with the cursor without issue.

jamesrusso commented 10 years ago

Actually just realized this should be opened against sqlanydb.

jamesrusso commented 10 years ago

Never mind, it actually belongs here. :-)

efarrar commented 10 years ago

Unfortunately, this is the expected behavior. As stated in the project README, "This backend has been tested with SQL Anywhere versions 12 and 16 ..." This should probably be updated to state that it requires version 12 or higher.

The reason for this is that Django makes heavy use of the syntax LIMIT X OFFSET Y in its SQL generation. This feature was not supported in SQL Anywhere until version 12.

When the LIMIT/OFFSET sytnax was added in Version 12, care was taken to not break any existing applications that were using the word "LIMIT" in other contexts (e.g. table name). As a result, to use the new LIMIT/OFFSET capabilities the connection first had to explicitly set an option (PUBLIC.reserved_keywords='LIMIT') to explicitly tell the engine to treat LIMIT as a reserved keyword.

In your case, because you are connecting to an Version 10 server, the query to treat LIMIT as a reserved keyword failed because LIMIT was not a reserved keyword in that version. You mention that after the initial failure, you are able to interact with the cursor without issue. However my guess is that if you try to issue a command that causes a LIMIT/OFFSET to be generated in the SQL, it will fail.

The driver should be modified to gracefully decline connections for any version < 12. Thank you for reporting this, and sorry for the inconvenience.

jamesrusso commented 10 years ago

Thanks for the explanation. I agree graceful decline would be better.

efarrar commented 10 years ago

Agreed. Have updated the issue title.

gperrow-SAP commented 9 years ago

With version 1.6 (uploaded today), this issue should go away unless you are using Django 1.1. With Django 1.2 or later, we now rewrite queries using LIMIT so that they use TOP instead, and so we don't need to set the reserved_keywords option at all.