Jani Tiainen wrote: > mkitezr kirjoitti: > >> That's funny Jani. My question about getting started was more just the >> downloading trac and start coding part. I have that and am starting a >> review. I would like to be respectful to the process established by >> the moderators/contributors of the project. Can I just go and create >> an "Oracle-compliant" branch off of trac 11 stable? I'm guessing no. >> So who do I talk to about really getting this formally started and >> creating a plan to actually address this, properly, completely, in a >> timely fashion, with the necessary support to keep it viable into the >> foreseeable future, and keep up with innovations with the rest of the >> trac's development? >> > > It's rather simple since all DB actions are done through DB backends > (trac.db.*_backend) > > >> As for the oracle problem, couldn't you create a proxy-like view that >> fixes the behaviour of strings appropriately using customized >> functions and/or operators? >> > > At the moment I was doing it didn't worked. I'm not sure was it actually > problem of cx_Oracle or Oracle itself but sometimes implicit conversion > between VARCHAR2 and CLOB just didn't worked. > > >> I'm pretty serious about getting this done and done right. I just need >> to know who to talk to, and if I need to talk to edgewall it would be >> nice to know who, and get them to answer my emails and perhaps get >> communicating directly. >> > > Keep in mind that there is bunch of very popular plugins that uses > handcrafted SQL to run queries too. > > That's a kind of a problem with Trac - instead of using real abstraction > layer between queries and database most queries as passed as is to DB > (or in most cases somekind of connection wrapper from backend) > > That's one reason why some people tried to make usage of some ORM, like > SQLAlchemy. > > Good place to start is to read how to contribute: > http://trac.edgewall.org/wiki/HowToContribute > > Trac is OSS after all and there is no "formal way" to start, but very > formal way to proceed. Also subscribing trac-dev mailing list is good > good thing todo, specially if you find out that you need to hack into > somewhere else than just plain backend (like queries itself in other > modules). >
Just let me add my 2 cents on the excellent answer you got from Jani. First, I'd welcome integrating an Oracle db backend, as this is something I always had on my long term plan. Second, SQLAlchemy would presumably help here, but given the amount of work a conversion represents, I'd still prefer to see an Oracle port in the more traditional style first (i.e. the same way we adapted for PostgreSQL and MySQL). Then we can see whether, as a second step, the switch to SQLAlchemy is still justified. These are only suggestions of course, if you feel like attacking the problem in a different way, feel free ;-) As for the process itself, start with patches, and if they look promising, we can certainly get you a place to play in our sandbox ;-) Also, don't bother starting on the 0.11-stable branch, rather pick the /trunk (or better yet, the /sandbox/multirepos, which is a step ahead). When maintaining the MySQL port, I could see that most of the trouble didn't come from the peculiar differences in the SQL dialect, but rather from the underlying differences in the database architecture itself. I expect this to be no different in the Oracle case. -- Christian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
