-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24.09.2012 09:13, Randall wrote: > I am involved in planning out getting Trac to work on a NonStop server. > We are working on the preliminaries (porting a good version of Python > and database support in there). I was wondering if there are any gotchas > that I need to watch out for in trying to port to a new database engine? > The native SQL is SQL/MX, which is fast and large, ANSI 2003 compatible, > full transactional support with statement isolation.
Gotchas? Plenty, I guess, or there would be much more supported Trac db backends these days. Admittedly, free availability and willingness to support more db's while still struggling with the existing ones, mostly MySQL, is another reason. I recommend to read on the issues for Oracle db support [1], or MS SQL server [2]. Although Trac core already has a very limited set of SQL statements, there are compatibility methods for the three currently supported backends to show you, how to approach a new db backend support. As far as I've learned * Python bindings (preferred) or equivalent * Unicode support * literally unrestricted length string fields * efficient full-text search capability on all fields are roughly the key criteria for Trac. Steffen Hoffmann [1] http://trac.edgewall.org/ticket/1874 [2] http://trac.edgewall.org/ticket/329 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBiJ+kACgkQ31DJeiZFuHdy7gCg36ErCZa2xh3OLp6VfUujITVZ LjAAn0fYiPNbySP4vDfcKS/WBQvCCW3H =mAEM -----END PGP SIGNATURE----- -- 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.
