Edgewall Software
Modify

Opened 16 years ago

Last modified 8 years ago

#6235 new enhancement

[PATCH] Adding support for Ingres as a backend DB

Reported by: AlexTrofast <alex.trofast@…> Owned by:
Priority: normal Milestone: unscheduled
Component: database backend Version: devel
Severity: normal Keywords: ingres db consider patch
Cc: Thijs Triemstra Branch:
Release Notes:
API Changes:
Internal Changes:

Description

This enhancement adds Ingres as a supported backend DB for Trac. The patch works against revision 6083. The only known issue is that there is no unicode/utf-8 support which will be addressed in the future.

Attachments (3)

trac_ingres_support.diff (15.2 KB ) - added by AlexTrofast <alex.trofast@…> 16 years ago.
Diff patch against revision 6083.
trac-ingres-v0.2.diff (14.1 KB ) - added by AlexTrofast <alex.trofast@…> 16 years ago.
Patch against revision 6142
ingres-trac-0.11.3.diff (9.6 KB ) - added by alex.trofast@… 15 years ago.
Diff against tags/trac-0.11.3 to enable Ingres support

Download all attachments as: .zip

Change History (25)

by AlexTrofast <alex.trofast@…>, 16 years ago

Attachment: trac_ingres_support.diff added

Diff patch against revision 6083.

comment:1 by Emmanuel Blot, 16 years ago

Milestone: 0.11

comment:2 by Emmanuel Blot, 16 years ago

Keywords: consider added; backend removed

Definitely not for 0.11.

I'm not sure about the addition for another DB backend: support for MySQL is already time-consuming.
Could it be added to the contrib directory or converted into a plugin ?

comment:3 by Christian Boos, 16 years ago

Milestone: 0.12

I think it should be possible to create an IDatabaseBackendProvider interface for adding db backends through plugins. That would also be a way to move the MySQL support out of the Trac base distribution…

Some of the changes in db_default.py look generally useful.

comment:4 by AlexTrofast <alex.trofast@…>, 16 years ago

It could possibly be added as a plugin, however there are changes necessary to three core files: search.py, model.py and db_default.py. If you are concerned about support, know that this patch will have Ingres's support behind it since I am working for them and Andrew Ross (andrew.ross@…, Senior Software Engineer) will also make sure that it is maintained. If there are any issues, we can always be reached and will address the problem.

in reply to:  4 comment:5 by AlexTrofast <alex.trofast@…>, 16 years ago

Replying to AlexTrofast <alex.trofast@ingres.com>:

It could possibly be added as a plugin, however there are changes necessary to three core files: search.py, model.py and db_default.py. If you are concerned about support, know that this patch will have Ingres's support behind it since I am working for them and Andrew Ross (andrew.ross@…, Senior Software Engineer) will also make sure that it is maintained. If there are any issues, we can always be reached and will address the problem.

Just correcting myself, cores files modified: search/api.py, query.py and db_default.py.

comment:6 by Noah Kantrowitz, 16 years ago

The DB backend system is already modular, so as long as the changes other than the ingres backend don't break an existing backend, I would say merge those and leave the backend itself in a plugin.

comment:7 by Andrew Ross, 16 years ago

I'd like to understand this better. How much time and effort is saved by making the back end a plugin vs. always integrated?

I'd hate to make end users do extra work based on a decision to avoid work (re-testing and maintaining Ingres support) that I'm happy to have my team do.

Please let me know how I can help solve this.

Thank you,

Andrew

comment:8 by Noah Kantrowitz, 16 years ago

Its a win for both groups really. Keeping it as a plugin means you aren't tied to Trac (admittedly slow) release cycles and internal nonsense. Its also just less code in Trac core, which lowers maintenance headaches.

comment:9 by Andrew Ross, 16 years ago

Thanks for the follow up.

Being coupled to Trac's release schedule in this case seems like a good thing given the Ingres supporting code is tightly coupled with Trac.

Having the various RDBMS supporting code present in base meant we could re-test and be assured that our changes did not break other implementations. Splitting things out into plugins would likely make things harder to test resulting in a higher chance of breakage, and longer turn around for fixes, no?

To have support for Ingres (or any RDBMS really) included means less work for end users which is definitely a good thing.

This doesn't have to be a permanent thing. If we try it as part of base for a release cycle, and we run into problems, we can always change the approach later. Please let me know if this is reasonable.

Thank you,

Andrew

in reply to:  9 comment:10 by Emmanuel Blot, 16 years ago

Replying to Andrew Ross:

This doesn't have to be a permanent thing. If we try it as part of base for a release cycle, and we run into problems, we can always change the approach later. Please let me know if this is reasonable.

-1 to integrate a whole collection of RDMBS backends in Trac core.
We don't even know how many users would be interested in having support for Ingres.

I don't think I'm wrong writing that MySQL is more popular than Ingres for web-based open source project. We are not even sure that support for MySQL in Trac core would not be dropped in favour of an optional plugin.
It would not make sense to add support for a less popular DB backend, whereas the officially supported DBs (SQLite and PostgreSQL) scale well from small to large Trac installations. Let's keep the (Trac) core small.

comment:11 by Andrew Ross, 16 years ago

Emmanuel,

You cited time/work/effort to support Ingres as a reason to do the plugin. I understand that. We're going to do the work, so perhaps that's less of a concern now.

You've now cited popularity. We feel there will be Ingres users who want to use Trac, and Trac users who want to use Ingres. Workload within reason, choice is a good thing. We're here to enable another open source RDBMS choice if the user decides. We'd like it to be as easy as possible to do so.

I'm concerned about support for Ingres being a plugin for obvious reasons. Netscape was a "plugin" compared to IE, and that didn't go so well. I'd really like to avoid making extra work for the user if we don't need to.

Please let me know if you have any further concerns and perhaps I might be able to address them.

Thank you,

Andrew

in reply to:  11 comment:12 by Emmanuel Blot, 16 years ago

Replying to Andrew Ross:

Please let me know if you have any further concerns and perhaps I might be able to address them.

I think I've expressed all of them in the previous comments. I understood you'd have liked that Trac natively supports Ingres, but I wish Trac core being kept small. Adding new DB backend(s) is an opposite goal.

When you write "the user" it only represents a (unknown, but likely small) fraction of Trac users. This is typically the reason to choose a plugin over an integration in the core.

comment:13 by Andrew Ross, 16 years ago

Emmanuel,

Isn't the underlying reason you choose to do a plugin rather than core to save effort? If so, then given we're going to do the work, isn't this reasonable to try for a while?

Andrew

in reply to:  13 comment:14 by Emmanuel Blot, 16 years ago

Replying to Andrew Ross:

Isn't the underlying reason you choose to do a plugin rather than core to save effort?

No / not only: the reason of the plugin architecture is to keep a core with the basic, common features of Trac and to enable plugins to implement the less "universal" features. It also allow to keep a small, lightweight engine that can be tailored and customized for various needs. Bloating it with non essential features is - I believe - what should be avoided.

If so, then given we're going to do the work, isn't this reasonable to try for a while?

I hope you'll get feedback from the main developers of Trac but IMHO, it isn't worth it.
There are plenty of supported plugins out there - in the Trac ecosystem - very few have been integrated to the core, because they are not essential for Trac.

comment:15 by Andrew Ross, 16 years ago

Hello Everyone,

Please let me know if there's anything we need to do to proceed with this to the next step. Also, please let me know if there's something we can do to help if the right people to review our request are currently busied out.

Thank you kindly,

Andrew

comment:16 by Christian Boos, 16 years ago

The core Trac team is indeed busy with the upcoming 0.11 release. Also, one thing I don't like so much in your patch is the lack of Unicode support. Is that a limitation of the DB itself? If so, there's little point in adding support for that backend. If not, please consider updating the patch. Another annoying limitation is the limitation in key size, a problem which has given much trouble with the MySqlDb backend as well (see #3676).

For the longer term 0.12, as I already wrote above (comment:3), either we'll make it possible to write plugins for DB backend or we'll adopt a 3rd party DB independence layer, most probably SqlAlchemy.

comment:17 by Andrew Ross, 16 years ago

Thank you for the reply.

We'll make sure the patch turns Unicode support back on. There was a bug on the Ingres side to limit the size the field which we didn't like. We'll resolve this and provide an updated patch soon.

We'll keep in touch between now and when 0.12 is being prepared. Please let me know what you decide regarding plugins, DB independence, or otherwise.

Thank you,

Andrew

by AlexTrofast <alex.trofast@…>, 16 years ago

Attachment: trac-ingres-v0.2.diff added

Patch against revision 6142

comment:18 by AlexTrofast <alex.trofast@…>, 16 years ago

trac-ingres-v0.2.diff enables unicode/utf-8 support and has increased size of the path index in node_change table. It can now hold 1,700 characters which should be sufficient in all situations.

Thank you,

Alex

by alex.trofast@…, 15 years ago

Attachment: ingres-trac-0.11.3.diff added

Diff against tags/trac-0.11.3 to enable Ingres support

comment:19 by Remy Blank, 14 years ago

Milestone: next-major-0.1Xunscheduled

comment:20 by Thijs Triemstra, 13 years ago

Cc: Thijs Triemstra added
Component: generaldatabase backend

comment:21 by Ryan J Ollos, 9 years ago

Owner: Jonas Borgström removed

comment:22 by figaro, 8 years ago

Keywords: patch added

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.