[PATCH] Adding support for Ingres as a backend DB

[AlexTrofast <alex.trofast@…>]

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.

[AlexTrofast <alex.trofast@…>]

Diff patch against revision 6083.

[eblot]

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 ?

[cboos]

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.

[AlexTrofast <alex.trofast@…>]

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.

[AlexTrofast <alex.trofast@…>]

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.

[nkantrowitz]

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.

[Andrew Ross]

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

[nkantrowitz]

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.

[Andrew Ross]

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

[eblot]

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.

[Andrew Ross]

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

[eblot]

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.

[Andrew Ross]

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

[eblot]

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.

[Andrew Ross]

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

[cboos]

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 3^rd party DB independence layer, most probably SqlAlchemy.

[Andrew Ross]

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

[AlexTrofast <alex.trofast@…>]

Patch against revision 6142

[AlexTrofast <alex.trofast@…>]

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