SQL Server support: In core for "1.0" or external-only?

[Adam V.]

The SQL Server backend in trunk is basically broken (parameter
replacement doesn't work right), as well as missing features
(introspection being the big one.)

There have been many proposed patches, though lots of them go back to
0.91, and make lots of changes outside of the backend as well.

On my more recent patch attempt, http://code.djangoproject.com/ticket/5947
, mtredinnick suggested making an external backend, which I've posted
on Google Code:
http://code.google.com/p/django-mssql/

I'm only a "sample size of one" at this point, running on Windows XP /
SQL Server 2005, so this backend only qualifies as "stuff I did to get
it working locally."

But given that the "1.0" release is getting closer and closer, I'd
love to know if Django intends to keep SQL Server support in the core,
or remove it and rely on external backends.

[Malcolm Tredinnick]

Coincidentally, Jacob and I were talking about this the other day,
mostly discussing the issues without attempting to reach a final
conclusion. My personal opinion is that it should be tossed. It hasn't
worked for ages and until somebody has a track record of supporting it
externally for a good while, it's a bit risky to continue to include it.

Malcolm

[Adam V.]

Looking in the query generation code (for both trunk and queryset-
refactor), there's special case code for RegEx clauses and Oracle, as
Oracle uses a function call syntax instead of an operator syntax.

It would be great to have this generalized for use with other engines.
SQL Server has no built-in regex operators, but it's pretty easy to
add as custom functions. These clauses would have to be added as
something like " dbo.MatchRegEx( [the value being tested], [the regex
string expression] ) = 1 ".

[Jacob Kaplan-Moss]

On 11/30/07, Malcolm Tredinnick <mal...@pointy-stick.com> wrote:
> Coincidentally, Jacob and I were talking about this the other day,
> mostly discussing the issues without attempting to reach a final
> conclusion. My personal opinion is that it should be tossed. It hasn't
> worked for ages and until somebody has a track record of supporting it
> externally for a good while, it's a bit risky to continue to include it.

In case it's not obvious from what Malcolm said, I'm +1 to removing
ado_mssql and directing MSSQL folks to outside backends.

Jacob