Oracle backend

3 views
Skip to first unread message

scott

unread,
Jun 17, 2008, 11:09:25 AM6/17/08
to Trac Users
Does Trac support using oracle as a backend database instead of
SQLite, PostgreSQL, or MySQL. If so is a specific version when it
started

Noah Kantrowitz

unread,
Jun 17, 2008, 12:57:02 PM6/17/08
to trac-...@googlegroups.com

No, the only well supported DBs are SQLite and Postgres. We include MySQL
mostly because people seem to insist on it, despite it being fundamentally
broken. The nice folks at Ingress contributed a backend plugin, but I'm not
sure where it ended up. The backend system is modular, so if someone wants
to write it, an Oracle plugin is probably possible. Mostly you just need to
do some API cleanups on the underlying library to make it match the others.
Our SQL is pretty standard, so I doubt that will be much of a problem.

--Noah

yoh...@gmail.com

unread,
Jun 17, 2008, 2:10:51 PM6/17/08
to Trac Users
Now, I am making a leap of assumption here, since i have not looked at
the code yet, but IF trac uses the python dbapi to access the various
db systems, wouldn't it be a matter of pointing it to use an oracle
version of it? which I believe already exists. Of course there are
about 3 too many asses in those umptions so, ....for what it is worth.

Noah Kantrowitz

unread,
Jun 17, 2008, 2:17:20 PM6/17/08
to trac-...@googlegroups.com

DB-API 2 is unfortunately a bit lax in some specifications. We make all the
DB libraries look like they use the %s paramstyle, and make sure they accept
and return Unicode strings. There are also a few auxiliary functions the DB
connector handles that aren't part of the database API itself, mostly schema
generation and casting syntax.

--Noah

Jani Tiainen

unread,
Jun 18, 2008, 1:02:13 AM6/18/08
to trac-...@googlegroups.com
Noah Kantrowitz kirjoitti:

Well I did attempt to do this but failed.

First, and most annoying feature in Oracle is dealing with '' (empty
string) as NULL.

So: select * from foobar where a = '';
evaluates to: select * from foobar where a = NULL; which in turn is
something that doesn't evaluate correctly.

Second thing is lack of user friendly text field. VARCHAR2 can hold up
to 4000 _bytes_ (not characters). There exists CLOB but that uses LOB
pointers that are not nice to use, and for example automatic type
conversions don't always apply.

Ticket related to this spesific issue:
http://trac.edgewall.org/ticket/1874

As stated, SQLAlchemy (or any really abstract DB or-mapper/layer)
_might_ help, but until it's implemented in Trac, there is not much of a
proof of that.

--
Jani Tiainen

Reply all
Reply to author
Forward
0 new messages