Planning for HP NonStop Port

[Randall]

Hello Trac Developers,

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.

Are there some resources I can look at for the database?

TIA,

Randall

[RjOllos]

On Monday, September 24, 2012 12:13:44 AM UTC-7, Randall wrote:

Are there some resources I can look at for the database?

The are some pages in TracDev [1], such as DatabaseApi [2] and DatabaseSchema [3], which might be helpful to you. Beyond that though, I think you are left with studying the source code.

[1] http://trac.edgewall.org/wiki/TracDev 

[2] http://trac.edgewall.org/wiki/TracDev/DatabaseApi

[3] http://trac.edgewall.org/wiki/TracDev/DatabaseSchema

[Steffen Hoffmann]

-----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-----

[Peter Suter]

On 24.09.2012 09:13, Randall wrote:

The overview page for the IDatabaseConnector extension point [1] links
to some discussions about creating backends for other database engines.

Besides the Oracle and MS SQL tickets, there's also [2] which summarises
the problems the Oracle_cx backend ran into:
* Lack of Autoincrement type
* CLOB columns in Indexes not supported
* CLOB can't be in PK's and length of PK is limited
* Different syntax of parametrized SQL
* Lack of LIMIT/OFFSET keywords in queries
* Oracle keywords as Table/Column names
* Parameter size limitation

Another idea might be to browse MySQL backend tickets. [3]

--
Peter

[1]
http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.db.api.IDatabaseConnector#AdditionalInformationandReferences
[2] http://trac-hacks.org/ticket/5487
[3]
http://trac.edgewall.org/query?keywords=~mysql&status=!closed&or&keywords=~mysql&resolution=fixed&group=status

[Randall]

Thanks everyone. This port looks to be pretty daunting at this time. It seems like an ANSI SQL engine is pretty out there from a likely port standpoint. I'm going to keep researching, but some of the capabilities are definitely going to be a problem. Let me know if you need help on abstractions.