Using Django with a non-relational back-end data store?
felciano
I'm looking for a python web framework to build web apps talking to a
non-SQL-based data store, similar to an RDF store for the semantic web.
I'm trying to find a toolkit with a sufficiently-factored database
abstraction layer that we could plug in our own. The server has its own
query language, which you can call over HTTP (RESTian), XML-RPC, SOAP,
etc, and which returns results as a serialized tuple list (i.e. a
table), so hopefully the impedance mismatch would not be too extreme.
I have looked at TurboGears, and through that project have come across
Django, which looks to be among the more mature frameworks. I am having
a hard time figuring out where to look to understand the dependencies
on SQLObject. Has anyone used Django to connect to a
non-SQLObject-based data store, either directly or by providing a
custom model-to-store mapping? I've read the ZODB thread from 2005, but
didn't seen anything else.
Thank you in advance for your time.
Ramon
Malcolm Tredinnick
> Hi --
>
> I'm looking for a python web framework to build web apps talking to a
> non-SQL-based data store, similar to an RDF store for the semantic web.
> I'm trying to find a toolkit with a sufficiently-factored database
> abstraction layer that we could plug in our own. The server has its own
> query language, which you can call over HTTP (RESTian), XML-RPC, SOAP,
> etc, and which returns results as a serialized tuple list (i.e. a
> table), so hopefully the impedance mismatch would not be too extreme.
All you need to do is turn them into Python objects or dictionaries (see
below for why) and you're set.
> I have looked at TurboGears, and through that project have come across
> Django, which looks to be among the more mature frameworks. I am having
> a hard time figuring out where to look to understand the dependencies
> on SQLObject. Has anyone used Django to connect to a
> non-SQLObject-based data store,
Django does not use SQLObject. I think you are still thinking about
TurboGears here.
Anything in Django that inherits from django.db.models.Model is fairly
tightly tied to Django's database backend: so SQL databases, etc.
If you want to get your data from another location, you can do that and
then just use Django's views and templates to present your data. Things
like generic views will not work without a bit of work on your part
(since they require something that works exactly like a model's query
interface), but they are just an aid in any case -- you do not lose any
functionality if you do not use generic views.
Before diving too deeply into putting a custom backend into the existing
model infrastructure, you should probably have a think about whether you
really need to (think about whether your are customising the right place
in the hierarchy). If you already have a way of accessing data and
getting it into Python objects, then you can probably live without
Django's ORM layer. After all, the views are just Python code, so they
can work with anything you like. The templates access everything using
attributes or dictionary keys or methods, so you pass them objects or
dictionaries and they do not care whether it's from Django's ORM or not.
Although the various layers in Django (models, views, templates) all
work well together, they are sufficiently orthogonal that they don't
rely on each other to operate, so you can happily use your own "model"
layer and that might be easier than trying to extend Django's model
layer to talk to your own backend.
Best wishes,
Malcolm