Edgewall Software
Modify

Opened 10 years ago

Last modified 5 months ago

#329 reopened enhancement

Adding support for Microsoft SQL Server as a backend DB

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

Description

Requesting the inclusion of the Microsoft SQL Server 2000 database.

Attachments (0)

Change History (23)

comment:1 Changed 10 years ago by 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)

comment:2 Changed 10 years ago by anonymous

  • Priority changed from highest to normal
  • Resolution set to duplicate
  • Status changed from new to closed

comment:3 Changed 7 years ago by henke.mike@…

  • Keywords ms sql microsoft sql server added

Any idea of this will be readdressed?

comment:4 Changed 7 years ago by anonymous

  • Summary changed from Database Inclusion to Adding support for Microsoft SQL Server as a backend DB

comment:5 Changed 7 years ago by anonymous

  • Milestone set to 0.12
  • Priority changed from normal to high
  • Resolution duplicate deleted
  • Status changed from closed to reopened

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

comment:6 Changed 7 years ago by anonymous

  • Milestone 0.12 deleted
  • Priority changed from high to normal
  • Resolution set to duplicate
  • Status changed from reopened to closed

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 Changed 6 years ago by 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!

comment:8 follow-ups: Changed 6 years ago by 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.

comment:9 Changed 6 years ago by 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.

comment:10 Changed 6 years ago by diroussel+trac@…

You can also use TOP.

SELECT TOP (10) * FROM TableA

comment:11 Changed 6 years ago by 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.

comment:12 in reply to: ↑ 8 Changed 6 years ago by anonymous

  • Keywords 2005 added
  • Resolution duplicate deleted
  • Status changed from closed to reopened

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 Changed 5 years ago by cboos

  • Resolution set to wontfix
  • Status changed from reopened to closed

No.

comment:14 in reply to: ↑ 8 Changed 5 years ago by 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?

comment:15 follow-up: Changed 4 years ago by 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)

comment:16 in reply to: ↑ 15 Changed 4 years ago by 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!

comment:17 follow-up: Changed 4 years ago by trac fan

  • Component changed from general to database backend
  • Milestone set to unscheduled
  • Resolution wontfix deleted
  • Status changed from closed to reopened

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

comment:18 in reply to: ↑ 17 ; follow-up: Changed 4 years ago by cboos

  • Resolution set to wontfix
  • Status changed from reopened to closed

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 Changed 4 years ago by cboos

  • Milestone unscheduled deleted

comment:20 in reply to: ↑ 18 ; follow-up: Changed 4 years ago by 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.

comment:21 in reply to: ↑ 20 Changed 4 years ago by cboos

  • Milestone set to unscheduled
  • Priority changed from normal to lowest
  • Resolution wontfix deleted
  • Severity changed from normal to major
  • Status changed from closed to reopened

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 4 years ago by cboos (previous) (diff)

comment:22 Changed 5 months ago by anonymous

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 Changed 5 months ago by jomae

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as reopened The owner will remain jonas.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from jonas to anonymous. Next status will be 'assigned'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.