Hi Rohit,
The main issue with implementing support for HBase will be the fact that
it's non-relational, and doesn't use SQL, and thus none of the existing
database backends make a good starting point.
You'd probably be depending on Alex Gaynor's query-refactor branch [1],
which contains the relevant changes to help support non-SQL backends;
that's not merged in yet, though there's a possibility it will be at
some point before or during the Summer Of Code.
Our main concerns would be:
- That this is a feature that people want (our top criterion for
eligibility). You'll be able to need to point us to some previous
discussion on the topic on either django-users, django-developers, or
otherwise show that other people do really want the Django model layer
to support HBase.
- That you're able to complete the project in the time given. The
Django model layer is a complex beast, and Alex was only accepted last
year to work on it as he had a proven track record of commits there.
We'd want to see some of the work you've done on Django or similar
projects relating to the area of model layers/ORMs.
If you think you can address these issues, I look forward to seeing a
GSoC proposal. Don't expect it to get through without some serious
debate, however.
Andrew
[1]:
http://code.djangoproject.com/browser/django/branches/soc2010/query-refactor
I'm not sure this is a good project for GSoC.
Firstly, Alex Gaynor worked on providing support for non-relational
backends in last year's GSoC; that code hasn't landed in trunk yet,
and may undergo some more modification before it does. If you were to
build a HBase backend for Django under the auspices of the GSoC, it
would need to use this interface. So, you're proposing a project that
will be working against an interface that is still a work in progress.
Secondly, HBase support itself (or support for any non-relational
store) is unlikely to end up in core any time soon. Therefore, you're
proposing to work on a project that won't become part of core. I'm not
saying that contributing to Django's broader community isn't without
merit, but Django has a limited number of GSoC slots, so we're looking
to get the most bang for our buck. Working on Django's core is an easy
win; if it's going to be an external project, it would need to be
something that a large part of Django's community would gain benefit
from (c.f., Armin Ronacher's template compilation proposal).
Lastly, I'm not convinced that a backend for a single data store is a
project that would be big enough for a Summer of Code. Alex built a
MongoDB backend as part of his GSoC work, and he also had to do a
bunch of refactoring of Django's query engine in order to make it
work. You're proposing a massive subset of the work that he proposed
(and delivered), which leads me to suspect that you won't actually
fill an entire summer with this proposal.
If you're still interested in the GSoC, we're still interested in
having you as an applicant. If you're looking for other GSoC project
ideas, the list on the wiki [1] has a bunch of other suggestions.
[1] http://code.djangoproject.com/wiki/SummerOfCode2011
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.