Adding support for Microsoft SQL Server as a backend DB

[anonymous]

Requesting the inclusion of the Microsoft SQL Server 2000 database.

[anonymous]

See ticket #126 - future changes may allow you to integrate with MS SQL Server, or any other relational database (as a replacement for sqlite)

[henke.mike@…]

Any idea of this will be readdressed?

[anonymous]

Re-opened. not Duplicate since request for Microsoft SQL Server not MySQL, SQLite, or PostgreSQL

[anonymous]

I think you misunderstand #126. The point is, I don't think anyone wants to work on maintaining MSSQL support in the core (nevermind that it would require a copy of MSSQL). The Trac devs' hands are full enough as it is supporting SQLite, MySQL, and Postgres. So this is something that would probably be better off waiting on until there's more generic DB support (SQLAlchemy?)

Also, please be fair with priority, milestone, etc

[anonymous]

Hmm… Then I don't think this is a duplicate of #126 either. #126 is fixed and this is clearly not. Maybe close with won't fix. So at least people understands your intention without have to running arround and reopen the ticket.

Thanks!

[slide_o_mix at hotmail dot com]

I have a rough implementation of an MSSQL backend. I am coming up against some issues though.

For instance, several queries from trac use "LIMIT 1" SQL syntax which is not supported by MSSQL.

I am not quite sure what to do about those queries. There are some other schema things that I've run into as well (many of the DB fields are of type TEXT, but this doesn't work for primary keys or indices in MSSQL).

Any ideas would be appreciated.

[diroussel+trac@…]

slide_o_mix, the LIMIT issue can be worked around, but it's not as succinct as using LIMIT. You have to use TOP n.

See ​http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=850&lngWId=5 for an example, you can probably find others too.

I'd be interested in you MS SQL port. You could put it on trac-hacks.org, there you'll get a project page and svn etc.

[diroussel+trac@…]

You can also use TOP.

SELECT TOP (10) * FROM TableA

[slide_o_mix at hotmail dot com]

I agree, that it can be worked around, the problem is that the trac api's use LIMIT in several places. I don't see a good way of abstracting whether to use LIMIT or TOP in those apis.

[anonymous]

Replying to slide_o_mix at hotmail dot com:

I have a rough implementation of an MSSQL backend. I am coming up against some issues though.

Does anybody have a Trac (Linux/Unix) setup working with a SQL Server 2005 database using unixODBC and FreeTDS?

Kind regards,

Stephan

[Christian Boos]

No.

[anonymous]

Replying to slide_o_mix at hotmail dot com:

I have a rough implementation of an MSSQL backend. I am coming up against some issues though.

For instance, several queries from trac use "LIMIT 1" SQL syntax which is not supported by MSSQL.

I am not quite sure what to do about those queries. There are some other schema things that I've run into as well (many of the DB fields are of type TEXT, but this doesn't work for primary keys or indices in MSSQL).

Any ideas would be appreciated.

Are you willing able to share your implementation?

[a nonny mouse]

Perhaps aim towards something generic? e.g. ODBC + SQL-92? (can't see why there's a need to be tied to specific backends)

[trac convert]

Replying to a nonny mouse:

Perhaps aim towards something generic? e.g. ODBC + SQL-92? (can't see why there's a need to be tied to specific backends)

Absolutely!

[trac fan]

"wontfix"? not ever? seriously?

It's 2011, why tie yourselves to specific products when everyone else is trying to promote interoperability?

Trac could take over the world if you made it available to those who are forced to use other DBMSs, just think how many SQL Server, Oracle 'shops there are!

[Christian Boos]

Replying to trac fan:

"wontfix"? not ever? seriously?

It's 2011, why tie yourselves to specific products when everyone else is trying to promote interoperability?

It's 2011, and one might wonder why we're still stuck with SQL at all…

Trac could take over the world if you made it available to those who are forced to use other DBMSs, just think how many SQL Server, Oracle 'shops there are!

I hope nobody forces you to use Trac…

So, let me state once again: we have absolutely zero interest in supporting MS SQL Server.

The db layer is pluggable, you could write a plugin which adds the support for this db backend if you'd like to.

[anonymous]

Replying to cboos:

Replying to trac fan:

"wontfix"? not ever? seriously?

It's 2011, why tie yourselves to specific products when everyone else is trying to promote interoperability?

It's 2011, and one might wonder why we're still stuck with SQL at all…

I presume you're supporting SQL because it's the most widely deployed techonolgy out there and you'd seriously be reducing your market if you didn't.

Trac could take over the world if you made it available to those who are forced to use other DBMSs, just think how many SQL Server, Oracle 'shops there are!

I hope nobody forces you to use Trac…

We're on your side here, no need to be defensive.

So, let me state once again: we have absolutely zero interest in supporting MS SQL Server.

Please re-read comments, this was more about ODBC/SQL-92…which in turn opens doors to other backends, for example SQL Server.

The db layer is pluggable, you could write a plugin which adds the support for this db backend if you'd like to.

Yes, but this is what the "enhancement" ticket type is for, you know - for people to ask Trac maintainers to do it.

If I ever have the time to do something, I will 100% submit it to the project, more than happy to help Trac move forward.

[Christian Boos]

Replying to anonymous:

Replying to cboos:

Replying to trac fan:

"wontfix"? not ever? seriously?

It's 2011, why tie yourselves to specific products when everyone else is trying to promote interoperability?

It's 2011, and one might wonder why we're still stuck with SQL at all…

I presume you're supporting SQL because it's the most widely deployed techonolgy out there and you'd seriously be reducing your market if you didn't.

Ah yes! I knew there must have been a reason ;-)

Please re-read comments, this was more about ODBC/SQL-92…which in turn opens doors to other backends, for example SQL Server.

Ok, point taken. I just stumbled upon ​pyodbc, which seems indeed to be an interesting project.

The db layer is pluggable, you could write a plugin which adds the support for this db backend if you'd like to.

Yes, but this is what the "enhancement" ticket type is for, you know - for people to ask Trac maintainers to do it.

Not really. Enhancement tickets are fine for proposing ideas (ideally backed by some code to at least bootstrap the proposal and show you're serious about it), it's not a way to have some developers do work for you. If we say we're not interested, well, we're not, and we close the ticket, as a way to notify people it's not a direction we want to take and also as a way to keep this Trac instance tidy with tickets we actually care about. However there's a middle ground, a "maybe" area, which is precisely the road we're taking now thanks to your precision about ODBC and the fact that an open sourced, ​cross-platform, Python library could be used for leveraging that technology.

If I ever have the time to do something, I will 100% submit it to the project, more than happy to help Trac move forward.

Thanks! It will all then depend on the quality of the code, the level of efficiency of such a solution, and the balance between the benefits for our users and the added maintenance cost. We have quite some requirements on what such a db api should be able to do, see #1874 for example to have a taste of the problems some people had for trying to use the Oracle backend. I would imagine that using ODBC as a way to access Oracle wouldn't make these problems go away. Note that we still have important issues with our supported backends, like MySQL (#8067). MySQL had to go through several years of improvements before support for unicode was working fine, for example. So adding support for a new db backend is all but a small undertaking.

[anonymous]

This is all very interesting but nothing I have read on this page actually describes how to use Sal databases rather than sqlite

[Jun Omae]

​th:MsSqlBackendPlugin supports partially SQL Server backend using ​pyodbc. Also, ​pymssql is DB-API interface to Microsoft SQL Server for Python binding.

[solsson]

We've resumed from where the trac-hack plugins left off. See ​https://github.com/Reposoft/trac-mssql.

Our trac instances will only run as a ticket backend, so we don't test the full Trac feature set. Wiki and timeline seem to work though.

Switched to pymssql because as a project it seems more maintained nowadays than pyodbc.

​https://github.com/Reposoft/trac-mssql

[figaro]

Removal of obsolete tag.