Introduction of resource-based Models
=====================================
My name is Sebastian Hillig and I currently study IT Systems
Engineering in Potsdam/Germany at the Hasso Plattner Institute.
I came to Django when exploring the "world" of web frameworks about
1.5 years ago and gladly got stuck to it. Therefore I am interested in
taking part in Google Summer of Code for Django.
The Proposal
------------
Models in Django are conceputally based on tables in a database. I'd
like to enhance that with the introduction of resource-based models.
The basic idea comes from Ruby on Rails' ActiveResource, which allows
for interaction between two sites through a RESTful API. I would like
to take this a step further and provide an implementation of this type
of interface not bound specifically to REST. The interface will be
generic enough to allow for different types of sources.
Let me explain the pieces of this system. There are models and
sources. Models define the data that a source can fetch. For purposes
to fit this in a short period of development, four months, I will
implement the following models and sources:
* RESTModel
* XMLSource
Here is a quick example of how this might look::
from django_resource_models import models, sources
class Product(models.RESTModel):
name = models.CharField()
class Meta:
source = sources.XMLSource("http://example.com/products/")
The model will define the fields that it wants to have access to
through the source. The RESTModel will simply be an abstraction on top
of XMLSource which will understand how to deal with the data given by
the source. It is not entirely required to explicitly define the
models in this way. One could use a call to `./manage.py inspectapi
url` to introspect the API and provide the code for integration.
Using the RESTModel above, one can perform similar QuerySet calls on
the API::
>>> Product.objects.all()
[<Product: Some Product>, <Product: Another Product>]
>>> Product.objects.filter(name__startswith='S')
[<Product: Some Product>]
The implementation of this would more than likely need to be done in-
memory and could result into performing less optimally than through a
database. However, this approach and method is "buyer beware" in that
the user will be fully understanding of what exactly this all means.
Another aspect that will need to be addressed is dealing with creating
data from this side::
>>> product = Product.objects.create()
>>> product.name = "Sebastian's Product"
>>> product.save()
>>> Product.objects.filter(name__startswith='S')
[<Product: Some Product>, <Product: Sebastian's Product>]
Another item of importance is integration with existing models::
from django_resource_models import models as resource_models
class Post(models.Model):
title = models.CharField(max_length=100)
body = models.TextField()
featured_product = resource_models.ForeignKey(Product)
>>> Post.objects.filter(product__name__startswith='S')
Allowing for that type of filtering may or may not be possible with
the current Django code. It will be a goal to see about trying to
accomplish this or if worse comes to worse it is disallowed.
The primary concern of this project is to provide a framework for
pluggable resources mapped to models, which are able to consume and
produce other resources than database tables. It wouldn't claim to
have magical powers and read the developer's mind but provide a
convenient set of (optional) functionalities like caching and
integration to the ORM by trying to make the developer only write as
much code as is really needed.
Rough Plan
----------
April 14th:
* Announcement of accepted students
Preparation phase (2-4 weeks parallel to other phases):
* Dig into the Django core, get a feeling and document model-
creation if
not done yet, look for points to hook in.
* Explore the REST-architecture
* Figure out solutions for problems like:
* ForeignKey integration
* Resource downtimes
* Making the base model as generic as possible without losing
functionality.
* Writing data back to resource.
* Caching and cache staleness detection.
* Handling resources that don't have a unique identifier.
* How to provide complete integration with the ORM (without
tables?)
* Ideal notation to satisfy generity
* Investigate the need for improvement for django-rest-
interface
April 26th:
Coding phase 1 (~4 weeks):
* Base model and base resource implementation
* Basic ORM integration
* Implementation of a dummy model and resource
June 15th:
* Start with integration of RESTModel and XMLSource
* Refine integration to ORM
* Caching
July 7th:
* MIDTERM EVALUATION
July 14th:
Coding phase 2 (3-6 weeks)
* Writeback to resource
* Refine ORM integration
* Finish integration of RESTModel and XMLSource
Rest of the time up to August 18th:
* Experiment with different sources
* Ensure good test coverage
* Documentation
* Documentation
* Documentation / although this is planned to be done in parallel
with the
other phases
Additional Information About Me
-------------------------------
I am Sebastian Hillig, situated in Berlin, Germany. Being 21 years
old, I recently finished my civil service and study IT Systems
Engineering at the Hasso Plattner Institute now, where I have finished
the first term these days.
My background: Right after finishing grammar school, I did a 5 month
internship at a local web development business, where I am currently
employed for part time work on their content management system.
This would be my first real involvement into open source development,
so I'd be glad to be given the opportunity to participate in the
highly interesting field of django development.
