Showing posts with label Python. Show all posts
Showing posts with label Python. Show all posts
Sunday, December 9, 2012
Rdbhdb, now for Python 3
Our DB API 2 module, called Rdbhdb, now suppports Python 3.
In the process of updating, I found a good new module.
The Python 2 version used the 'encode' module from the Poster package. That module has not been ported to Python 3, so I went looking for a new module to do multipart form-data encoding. I found the Requests package on PyPI, and borrowed the 'filepost' module from that. It works well. In my search, I had opportunity to look over the Requests API, and it is an elegant API, doing the http request functionality in straightforward ways. If I were writing my own module now, I would use Requests, in lieu of HttpLib/Urllib as I did.
Back to Rdbhost: the new Rdbhdb module is in the same Github repository as the old, where the two are seperated into different folders. Each is complete, with setup.py and test suite.
David Keeney
https://github.com/rdbhost/Rdbhdb
http://www.rdbhost.com
https://www.rdbhost.com/howpython.html
.
Boilerplate
Rdbhost is a tool for getting simple web apps going quickly.
In support of that position, we now have boilerplate bundles; these are downloadable zip files that can be unzipped to your harddrive, and immediately function as simple applications. Your account information is already embedded in each, so it will just run, and access your Rdbhost account as necessary.
The wizard collects from you the necessary information to create the boilerplate bundle. After the wizard completes, you can download the relevant bundles from the boilerplate page; each includes a README.txt with starter instructions.
For now, there are as many as three boilerplate bundles, depending on your wizard selections; one for the Python Rdbhdb module, one for Python's SQLObject, and one for a JavaScript web app. There will be more, in time, including options for html boilerplate, and these (especially the JavaScript bundle) will be enhanced.
Try them out, let me know if they don't behave as expected.
David Keeney
dkeeney@rdbhost.com
Sunday, November 28, 2010
Django?
I suspect that the Django ORM gets more use than either SQLObject or SQLAlchemy, just because it is part of the Django stack, included in Django installs by default. For this reason, I would like to include Rdbhost support in Django.
A day plus spent in pursuit of that goal has been fruitless. This post is a summary of my experience.
Before I announce support for an ORM or framework, I try to ensure that as much as possible of the framework's tests pass with this database. I found Django's testing tools difficult to understand and difficult to use.
I started testing in an app, with 'manage.py test', until someone cued me in to the runtests.py utility; the Pip/easy_install version of Django does not include most of the test suite, so when I found out, I switched to the tarball version.
Testing with runtests.py worked better, but still not great. Firstly, it seemed to ignore the '--fastfail' switch when the failure was an exception (an Error, in testing parlance), rather than a negative result of an assertion (a Fail). Most 'failures', for me, will be exceptions, and --fastfail should abort on them, as do unittest and py.test with the -x switch.
runtests.py doesn't abort on Error, and its error message is just 'ERROR', without a test name or line number or anything. Aborting with a ctl-C will abort the test run, but will not display the test report for prior failures. So the only way to get a test result (with test name and stack-trace) displayed for an exception is to wait for the batch of tests to complete, which could be 20-50 tests and take upwards of 10 minutes. This is an extremely tedious way to diagnose problems.
When you do have the name of a test, like 'modeltests.aggregration.tests.BaseAggregateTestCase', and try to run it specifically, with 'runtests.py modeltests.aggregration.tests.BaseAggregateTestCase', you get an error about 'test labels' and 'app...'
When I tried to runtests.py with a simple 'sqlite3' based settings file, I still got many errors, failing on 25-35% of the tests. This casts doubt on whether the test suite itself is maintained, and it is very frustrating to try to get a component to comply with test expectations when you cannot be sure the tests aren't themselves broken. The test runner seemed to find the json fixtures when running with the sqlite3 settings, but not with the rdbhost settings. Why would retrieving data from a file in the distro depend on what backend was configured?
The test suite looks fairly comprehensive, but without a test runner that will run specific tests in a predictable way, developing to the tests is not practical. The Django compatibility effort here is on the shelf for a while.
A day plus spent in pursuit of that goal has been fruitless. This post is a summary of my experience.
Before I announce support for an ORM or framework, I try to ensure that as much as possible of the framework's tests pass with this database. I found Django's testing tools difficult to understand and difficult to use.
I started testing in an app, with 'manage.py test', until someone cued me in to the runtests.py utility; the Pip/easy_install version of Django does not include most of the test suite, so when I found out, I switched to the tarball version.
Testing with runtests.py worked better, but still not great. Firstly, it seemed to ignore the '--fastfail' switch when the failure was an exception (an Error, in testing parlance), rather than a negative result of an assertion (a Fail). Most 'failures', for me, will be exceptions, and --fastfail should abort on them, as do unittest and py.test with the -x switch.
runtests.py doesn't abort on Error, and its error message is just 'ERROR', without a test name or line number or anything. Aborting with a ctl-C will abort the test run, but will not display the test report for prior failures. So the only way to get a test result (with test name and stack-trace) displayed for an exception is to wait for the batch of tests to complete, which could be 20-50 tests and take upwards of 10 minutes. This is an extremely tedious way to diagnose problems.
When you do have the name of a test, like 'modeltests.aggregration.tests.BaseAggregateTestCase', and try to run it specifically, with 'runtests.py modeltests.aggregration.tests.BaseAggregateTestCase', you get an error about 'test labels' and 'app...'
When I tried to runtests.py with a simple 'sqlite3' based settings file, I still got many errors, failing on 25-35% of the tests. This casts doubt on whether the test suite itself is maintained, and it is very frustrating to try to get a component to comply with test expectations when you cannot be sure the tests aren't themselves broken. The test runner seemed to find the json fixtures when running with the sqlite3 settings, but not with the rdbhost settings. Why would retrieving data from a file in the distro depend on what backend was configured?
The test suite looks fairly comprehensive, but without a test runner that will run specific tests in a predictable way, developing to the tests is not practical. The Django compatibility effort here is on the shelf for a while.
Tuesday, January 5, 2010
Rdbhdb 0.9.2
I've been working lately on making Rdbhost work better with ORMs, such as SQLObject and SQLAlchemy. One outcome of that effort is improvements to Rdbhdb.
A new release is out, version 0.9.2 with a couple of new features:
http://www.rdbhost.com/downloads/rdbhdb-0.9.2.zip
http://pypi.python.org/pypi/rdbhdb/0.9.2
A new release is out, version 0.9.2 with a couple of new features:
- Fields fetched are now converted into datetime.Date, datetime.Time, datetime.Datetime, and decimal.Decimal objects, depending on type.
- Times and Timestamps now have microsecond resolution.
- Parameters provided to .execute* calls are now typed, so the server can return each data item, as necessary, in the appropriate type.
http://www.rdbhost.com/downloads/rdbhdb-0.9.2.zip
http://pypi.python.org/pypi/rdbhdb/0.9.2
Friday, December 4, 2009
Rdbhdb 0.9.1
The DB API module, Rdbhdb, has been re-released. Only two changes in this version:
http://www.rdbhost.com/downloads/rdbhdb-0.9.1.zip
http://pypi.python.org/pypi/rdbhdb/0.9.1
- https (TLS) is used by default.
- A bug causing incompatility with Python 2.4 was fixed. 2.4 does not have an 'any' builtin, so the module provisionally provides one.
http://www.rdbhost.com/downloads/rdbhdb-0.9.1.zip
http://pypi.python.org/pypi/rdbhdb/0.9.1
Monday, October 26, 2009
Rdbhdb v 0.9
A new version of Rdbhdb is available from Pypi. Rdbhdb is the DB API 2.0 module for accessing Rdbhost databases remotely from Python applications.
Rdbhdb v 0.9 download page on PyPI
Rdbhdb v 0.9 download page on PyPI
Rdbhdb v 0.9 download page on Rdbhost
New in this version:
This version is the one currently in use on rdbhost.appspot.com, for its monitoring function.
New in this version:
- Uses gzip decompression, optionally, for data downloads from server.
- Supports the sending of binary data (as buffer datatype) in query parameters.
- .execute_deferred() method provided to execute queries in deferred mode. Deferred mode does not return results, but allows a more generous time limit for query completion. Useful for updates or inserts that might need extra time.
- .nextset() method implemented on cursors. Multiple queries can be aggregated into a single .execute() call, delimited by ';'. One result set is returned for each query, and .nextset() advances to the next result set in the returned list.
- .https attribute added to connection, to force use of SSL. Defaults to False, no SSL.
This version is the one currently in use on rdbhost.appspot.com, for its monitoring function.
Edited 28 Oct 09: Added rdbhost hosted download link.
Edited 9 Nov 09: Spelled PyPI properly
Subscribe to:
Posts (Atom)