Edgewall Software
Modify

Opened 20 years ago

Last modified 6 years ago

#329 new enhancement

Adding support for Microsoft SQL Server as a backend DB

Reported by: anonymous Owned by:
Priority: lowest Milestone: unscheduled
Component: database backend Version: none
Severity: major Keywords: ms sql, microsoft, sql server
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

Requesting the inclusion of the Microsoft SQL Server 2000 database.

Attachments (0)

Change History (26)

comment:1 by anonymous, 20 years ago

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

comment:2 by anonymous, 20 years ago

Priority: highestnormal
Resolution: duplicate
Status: newclosed

comment:3 by henke.mike@…, 16 years ago

Keywords: ms sql microsoft sql server added

Any idea of this will be readdressed?

comment:4 by anonymous, 16 years ago

Summary: Database InclusionAdding support for Microsoft SQL Server as a backend DB

comment:5 by anonymous, 16 years ago

Milestone: 0.12
Priority: normalhigh
Resolution: duplicate
Status: closedreopened

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

comment:6 by anonymous, 16 years ago

Milestone: 0.12
Priority: highnormal
Resolution: duplicate
Status: reopenedclosed

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

comment:7 by anonymous, 16 years ago

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!

comment:8 by slide_o_mix at hotmail dot com, 16 years ago

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.

comment:9 by diroussel+trac@…, 16 years ago

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.

comment:10 by diroussel+trac@…, 16 years ago

You can also use TOP.

SELECT TOP (10) * FROM TableA

comment:11 by slide_o_mix at hotmail dot com, 16 years ago

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.

in reply to:  8 comment:12 by anonymous, 15 years ago

Keywords: 2005 added
Resolution: duplicate
Status: closedreopened

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

comment:13 by Christian Boos, 15 years ago

Resolution: wontfix
Status: reopenedclosed

No.

in reply to:  8 comment:14 by anonymous, 14 years ago

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?

comment:15 by a nonny mouse, 14 years ago

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

in reply to:  15 comment:16 by trac convert, 13 years ago

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!

comment:17 by trac fan, 13 years ago

Component: generaldatabase backend
Milestone: unscheduled
Resolution: wontfix
Status: closedreopened

"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!

in reply to:  17 ; comment:18 by Christian Boos, 13 years ago

Resolution: wontfix
Status: reopenedclosed

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.

comment:19 by Christian Boos, 13 years ago

Milestone: unscheduled

in reply to:  18 ; comment:20 by anonymous, 13 years ago

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.

in reply to:  20 comment:21 by Christian Boos, 13 years ago

Milestone: unscheduled
Priority: normallowest
Resolution: wontfix
Severity: normalmajor
Status: closedreopened

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.

Last edited 13 years ago by Christian Boos (previous) (diff)

comment:22 by anonymous, 10 years ago

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

comment:23 by Jun Omae, 10 years ago

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

comment:24 by solsson, 9 years ago

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

comment:25 by Ryan J Ollos, 9 years ago

Owner: Jonas Borgström removed
Status: reopenednew

comment:26 by figaro, 6 years ago

Keywords: 2005 removed

Removal of obsolete tag.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.