Hello all: I just want to let everyone know what has happened on this proposal in the last little while.
1) The combination of a Linux (or Windows) database client with a Windows proxy database server is up and running. The remote supports all of the features of adodbapi (when run locally) except: custom error handlers, user-defined conversions, and manipulation of module values-that-really-ought-to-be-constants. I ended up using Pyro4 as the connection method. It has performed well. The default operation was remarkably good, and after a bit of work on timing and retry logic, it passes tests even across VLAN on a less-than-wonderful Nigerian Internet. I have tested briefly using Python 2.5 and 3.3, IPv6, and extensively using Python 2.7 on IPv4. My final test consisted of the two suites (dbapi20 and adodbapitest) running on Ubuntu 13.4, using two Windows proxy servers, one serving SQL Server (on Windows Server 2008), the other (Windows 7) serving Jet, MySQL, and PostgreSQL. The latter two database were in America on different Ubuntu servers, so this was not a trivial test. I will not release this version of adodbapi until I have had time to do more extensive testing with IronPython and Python 3.2 -- besides, I am still making minor adjustments as django integration continues. 2) The code changes to have django-mssql.base call adodbapi, rather than its built-in fork are complete. The forked code has been removed from my copy, and django is starting to run its tests. The creation and deletion of the test database are done in autocommit mode, so I had to use switched autocommit (newly supported in adodbapi). The backend now defaults "autocommit = django.VERSION > (1,6)" and allows settings.AUTOCOMMIT to override the default. [The Manfre/Thompson fork already had a form of switchable autocommit, so the adaptation was trivial. They had already done the hard work.] This is all running django on Windows using the 1.5 stable branch. 3) I will try to support 1.5 and 1.6 from the same code base. I have not found any sticky spots yet. 4) Today, I plan to try the same tests with django running on Linux using the proxy server. The only change should be adding <<settings.OPTIONS.proxy_host = '192.168.200.20'>> to my configuration. The backend will switch to using the proxy adapter when it sees that option. I am toying with an "auto_proxy" option which turns on auto-magically when it sees that it is running on non-Windows. Is that too much, or a good idea? What if it is called "macro_auto_proxy"? -- Vernon Cole -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
