GSoC proposal: Resource-based Models

[sebastia...@gmail.com]

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.

[David Larlet]

Le 2 avr. 08 à 02:09, sebastia...@gmail.com a écrit :

>
>
> 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.

I couldn't be more interested in a GSoC because that's exactly what I
miss in Django. Thanks for proposing that project, I really hope it
will be accepted and count me on for extending the base with at least
RDFModel once you setup the base. I'm already dreaming of some kind of:

class User(models.RDFModel):
user = whatever(DjangoUser.name)
# mmh, I need more time to think about the way to declare triples

class Meta:
source = sources.FOAFSource()

Good luck!

Cheers,
David

[Ben Firshman]

I am also extremely interested. This is exactly what I need for a
project I'm currently working on and one I may be working on for this
year's SoC.

Let me know if it gets accepted - I'd love to discuss it with you and
I can help test.

Thanks

Ben

[Rajeev J Sebastian]

Btw, RDFAlchemy provides a kind of ORMish layer. I am using it
currently in one of my semweb projects though it hasnt yet reached the
power of ActiveRDF.

Regards
Rajeev J Sebastian