Changes between Initial Version and Version 1 of Ticket #329, comment 21
- Timestamp:
- Jan 28, 2011, 3:36:40 PM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #329, comment 21
initial v1 19 19 > Yes, but this is what the "enhancement" ticket type is for, you know - for people to ask Trac maintainers to do it. 20 20 21 Not really. Enhancement tickets is 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, [http://code.google.com/p/pyodbc/wiki/Building cross-platform], Python library could be used for using that technology.21 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, [http://code.google.com/p/pyodbc/wiki/Building cross-platform], Python library could be used for leveraging that technology. 22 22 23 23 > 24 24 > 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. 25 25 26 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 problem 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.26 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. 27 27
