On Oct 7, 2007, at 5:28 PM, David Peckham wrote:
> > First, I'd like to thank Trac developers. I installed Trac for my > data warehouse team at work last week and we're already communicating > more effectively. I'm looking forward to bringing our business users > into Trac in the next few weeks. > > For now I'm running Trac on a spare Windows desktop. I want to move > this to a production web server and database server in the near > future. Since our infrastructure team supports Oracle and Microsoft > SQL Server, I'll have to make the case for SQLite, PostgreSQL, or > MySQL as a short term solution. Postgres is the best option for large sites right now. > > In the long term, I'd like to see Trac support Oracle or SQL Server. > I'm still relatively new to Python and Trac, but I'd like to > contribute. Can someone tell me what remains to be done with > SQLAlchemy and where I can help? "A lot". As SQL is not a very standard standard, the way most ORMs deal with cross-DB magic is to force you to use their object layer. Trac has already done this for schema generation (as that is more non- standard than most things), but we still use raw SQL for most queries. Beyond the work involved in moving everything to an ORM, we need to actually decide this is a wise course of action. The DB system is already modular, so as long as the query syntax for your DB of choice is the same as the others we use, you should be able to make a backend plugin. --Noah --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" 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-dev?hl=en -~----------~----~----~----~------~----~------~--~---
