Using Oracle instead of PySQlite

[vinodbabumv@…]

We are trying out to implement Trac for CM. Is there any way to use Oracle as back end instead of PySqlite. If there is any configuration change to be done please let me know.

[anonymous]

You might want to look at how PostgreSQL support is done. Trac appears to be using psycopg driver, but that's all I know.

[Rede]

I tried to write Oracle backend but I run in several serious issues and decided to cease my efforts.

• Oracle is very picky about field types in join queries. Specially it is big problem with CLOB and non CLOB fields.

• Oracle really has not decent equivalent to "TEXT" fieldtype in Oracle you have "CLOB" but using CLOB is really PITA.

• Oracle doesn't support empty strings. It translates empty string to NULL which makes problems in some queries. You cant do SELECT * FROM FOOBAR WHERE MYTEXTFIELD = '' because Oracle translates where clause to WHERE MYTEXTFIELD = NULL and all you know how true that is.

Unless you can convice Oracle to provide decent long-textfield support I really doubt that we'll se Oracle as direct backend to Trac.

But there is workaround: You can use Oracle Heterogenous Services or Oracle Transparent Gateways. I've user first one few times to read Excel data via ODBC. Works great. This would work so that you setup, i.e. ODBC driver to access Trac DB (postgre or sqlite I think both has ODBC driver available) and then setup Oracle to read Trac db. Now you can access your Trac data from Oracle.

[phoenix@…]

Hi! We'd love Oracle as a backend, as we have all other databases in there, only the Trac DB missing… Is there any advance on this topic?

[anonymous]

which oracle version did you try?

[ccidral.newsbox@…]

Is there any hope to get this implementation done given all obstacles provided by the Oracle SGBD stated in the comment made by Rede?

[jtiai]

I might give a second shot with this new database backend since it would enable to do lot of things without hacking Trac source itself and due the fact that there is this new Oracle XE that can be used without any fees.

It doesn't remove problems but might provide workaround.

[Matthew Good]

I am working on removing Trac's custom DB-abstraction layer in favor of ​SQLAlchemy which supports additional databases including Oracle. As Rede mentioned, Oracle has a number of issues that make it very difficult to integrate with Trac's database layer. Until we have a more advanced database layer such as SQLAlchemy we won't be able to support Oracle. This is being worked on in sandbox/sqlalchemy

[vintiverma@…]

Any update on TRAC's support for Oracle as back end. Have changes been completed in the database layer to support Oracle.

[anonymous]

Any idea to reconsider this?

[anonymous]

Replying to mgood:

I am working on removing Trac's custom DB-abstraction layer in favor of ​SQLAlchemy which supports additional databases including Oracle. …snip… This is being worked on in sandbox/sqlalchemy

The old sandbox/sqlalchemy link above was moved more than once. It appears to now be here: sandbox/Attic/sqlalchemy-ng. Since that project is in the "Attic" maybe it was never finished?