[IronPython] Database Engine for Django on IronPython

[Vernon Cole]

Please pardon all the typos I am about to make. Wife has taken me to
Yellowstone to see the bison migration. Am typing under my sleeping
bag...

I have been thinking About this in re STORM too. Perhaps the best way
would be like:

Try:
    Import prefferedDb as db
    Db.version = 'native'
Except:
    Import adodbapi as db
# then later if needed
If db.version = 'native':
  # do usual thing
Else:
   # do ado thing
....
So all of the database specific stuff remains in that module, which
will then use ado if the preffered ifc is not available.
--
Vernon

Sent from my Windows Mobile phone

-----Original Message-----
From: Markus Törnqvist <mjt at nysv.org>
Sent: Saturday, October 24, 2009 2:58 AM
To: Discussion of IronPython <users at lists.ironpython.com>
Subject: Re: [IronPython] Database Engine for Django on IronPython


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
Django's interface?

I think the answer is no...

I'm looking at SQLite again, in Django, because it too uses the qmark
syntax.

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.

>For example,
>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.

> I
>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
such functions..

-- 
mjt

_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com