Adding or modifying columns makes assumptions on SQL syntax about django-evolution HOT 5 CLOSED

There's no direct support in Django Evolution for SQL Anywhere. How are you using this today?

I'm happy to take a patch that adds such support, so long as it doesn't impact any other backends. (Just FYI, we don't use pull requests. Patches must be posted to https://reviews.reviewboard.org/.

from django-evolution.

I work for SAP in SQL Anywhere engineering, and I'm in the process of writing a driver for SQL Anywhere. The problem is that the 'op' field is used both to distinguish between different ALTER operations and as the actual SQL syntax. There needs to be a way to say "I'm doing an ADD COLUMN operation, but the SQL clause to use is 'ADD'".

from django-evolution.

Ah, I see.

So my first stab at what I think we should do (and, not working through this problem myself, I might be wrong), is to remove the hard-coded names in sql_result.py, and instead refer to constants on the backend's class for those names. The defaults would be 'MODIFY COLUMN' and 'ADD COLUMN', but your backend could change those to 'ALTER' and 'ADD'. The list could then be updated to refer to those.

That way, the op remains what it is today, the actual ALTER TABLE operation being performed. The backend is in complete control of the name.

If even more specialized logic/formatting is needed, I'd then suggest to break out that bit of logic further into a function that the backend can override in order to better prepare its ALTER TABLE statement.

Does that sound like it'd work? Or is there a gotcha somewhere?

from django-evolution.

That sounds right.

from django-evolution.

Long overdue, but with the new major rewrite, it's now possible for backends to implement their own version of the AlterTableSQLResult. SQLite has its own, which it processes and turns into suitable SQL.

from django-evolution.