[IronPython] Database Engine for Django on IronPython
mjt at nysv.org
Sat Oct 24 01:58:35 PDT 2009
On Fri, Oct 23, 2009 at 04:36:27PM -0600, Vernon Cole wrote:
>So it would appear that if I always use the OleDb provider, then I always
>have qmark parameter style, even if I am opening an Oracle data base. The
>conversion from pyformat to qmark would be done programatically in adodbapi.
>There may still be a problem with differences in dialect between different
>SQL engines. I think many of those are coded in to the various database
>front ends, so that an "interchangable" adapter would still need to know
>what engine it is using and make some changes to adapt itself.
Yeah, well, the problem would be:
Can you represent all adodb-supported databases generally through
I think the answer is no...
I'm looking at SQLite again, in Django, because it too uses the qmark
Django defines the SQLite interface classes, like most importantly here
SQLiteCursorWrapper, which has a method for changing the Python-formatted
query to qmark.
So then when the underlying SQLite db api executes the query, it gets it
understandable qmark format and knows what to do with it.
For adodb to pull this off, you'd (correct me if I'm wrong here!) need
a) One Django db backend per adodb backend
b) A configuration mechanism for the one unified adodb Django backend
Somehow I'd tend to be in favor of option a) and then see from mssql
onwards if all backends need to be supported.
Option b) sounds like a path to some hackiness through a lot of work.
>do you use "TOP" or "LIMIT" to restrict the number of rows requested? MS-SQL
>uses "TOP" while MySQL uses "LIMIT", both through the OleDb provider.
Yeah, the DatabaseWrapper class has an operators attribute, with some
db-specific stuff, but it does not do modifications as heavy as those.
>definitely do not want to be restricted to only MS-SQL from
>IronPython/django. The existing django-mssql code is engine specific. I
>would like to remove that restriction, but do not know (yet) if that is
>possible. adodbapi itself is engine agnostic.
Yeah, I understand, but what would the semantics look like?
Would there be something like
DATABASE_ENGINE = 'adodb'
ADODB_ENGINE = 'access'
and then django.db.backends.adodb.base (that's the base.py file)
has checks like
# FIXME: This could be an __import__ joke without if checks
if ADODB_ENGINE == 'access':
from _adodb_backends.access import *
and you'd effectively end up doing multiple backends anyway, right?
Looking at the tutorial and connection examples, at least different
backends have very different ways of connecting. That should probably
not be a show-stopper though.
SelectLimit came up, and Django implements it in a sort of roundabout way.
You must remember QuerySet objects are lazy, so the query gets executed
when you actually do something with it.
When you retrieve a slice of it, the queryset's set_limits() method
gets called, which puts in high_mark and low_mark values. In my
Django 1.0.4 sources this is Django-1.0\django\db\models\sql\query.py
like 1459, and then in the sql-generating method as_sql() on line 298
you see how the limit/offset stuff is done.
Looking at django-mssql they have a very ingenious approach to it, the
as_sql() method performs a regexp substitution.
This has, however, nothing to do with SelectLimit, so it makes me kind
of think if Django's ORM should be used with ADODB without the help of
More information about the Users