Re: [GSOC] Introduction and task proposal

[Aymeric Augustin]

On 19 mars 2014, at 06:27, Zach Borboa  wrote:

> Curious, how do you get REPL shell access to the server with DEBUG=True with 
> a vanilla Django deployment?

That part of the discussion was about adding the werkzeug interactive debugger 
to Django's default error page.

-- 
Aymeric.




-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0BA238DA-E4BE-4ACB-A5ED-C405ED190DEF%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Saving forms without validation, and formsets

[Chris Wilson]

Hi Carl,

On Tue, 18 Mar 2014, Carl Meyer wrote:

On 03/18/2014 02:54 PM, Chris Wilson wrote:


1. GCBV and Vanilla Views do a great job for simple forms, but they
leave out embedded formsets entirely. (For example our large form has
repeating sections for employment history, education, etc.) It feels
like it would be great to have formsets handled "more automatically" -
instantiating, validating and saving them just like we do for forms. A
lot of our code is shared between all our formsets, and potentially
reusable.


The approach I've used for this is encapsulating the creation and
handling of the inline formsets entirely within the "parent" form class,
so from the perspective of the view it acts like a normal simple form.


That seems like an excellent idea, thanks! I'm reworking my forms to work 
this way.



This requires overrides of a few methods on the parent form: __init__()
to create the formsets, is_valid() to ensure the formsets are valid too,
has_changed() to see if formsets have changed, and save() to save
formsets too.


There's a few more Form methods that I'm not sure whether I need to 
override, especially if I want to be able to generalise this. I think just 
_get_media and is_multipart should take sub-formsets into account?



If we were going to look at incorporating something into Django, I'd
like to consider this option as an alternative to adding more GCBVs with
inline-formset support. I think it's a nicer abstraction (because in a
real sense those inlines are "part of" the parent form), and I don't
think we want to add to the already-extensive list of GCBVs and mixin
classes.


I agree. Then it should also work for Vanilla Views with no changes.


I think either approach would be workable as a third-party project, too.


I think it would be nice for forms to be able to treat embedded formsets 
as a special (complex) type of 'field', so that as_table, as_p etc. would 
render the formsets as well, and for ModelForm to be able to generate 
these automatically for models with ForeignKeys that link back to the 
ModelForm's Model.



2. Adding instances to a formset on the client side using Javascript.
There is a django-formset-js package on PyPI, but it requires special
attributes to be added to form elements that would have been difficult
with crispy forms (which we're also using) and it feels almost like this
functionality ought to be in Django core (maybe not today, but one day?)


I've used this: http://plugins.jquery.com/django-superformset/


Thanks for the tip, I didn't know about that one.


3. We couldn't change the "extra" of a formset without redefining the
formset class. We wanted to do this because the required repeating
sections (employment history etc.) must not have a blank form in them if
they already have some valid forms, otherwise the blank forms prevent
the form being submitted because HTML5 client-side validation fails. So
we had to do all this:


I don't understand this. The 'extra' attribute of a formset class can be
tweaked dynamically as a normal attribute (although this may not be
documented); it doesn't require recreating the entire formset class.


I'm not sure that's possible, because inline_formset defines a new class. 
That class has a class attribute called 'extra' containing the value of 
'extra', but changing it would change it for all instances of the class, 
so it's not thread-safe. And when the class is instantiated, the value is 
immediately used to create the initial empty forms, and not used after 
that, so changing it after instantiating the form has no effect. Thus, it 
seems that we have to subclass BaseFormSet anyway to get into the 
constructor and change the value of extra before the initial forms are 
created.


I snipped your last three items, regarding saving invalid forms. I think 
this is an unusual use case, and I'm not sure support for it belongs in 
core. It would be interesting to experiment with something to make 
filefields less painful when validation fails, but that can be a 
third-party project first I think.


It may be unusual, but I'm not the only one to want this. At least two 
people participated on this SO question:

http://stackoverflow.com/questions/8993749/transform-an-unbound-form-to-a-bound-one

From there I got my current approach, which is to use model_to_dict to 
create a fake 'data' to make the unbound form bound, so that I can 
validate it. However this is ugly, and it doesn't work with formsets 
because it doesn't account for the management form, which complains about 
having been tampered with because its data is missing. And there's no 
form_to_dict equivalent of model_to_dict, so I'd have to hack something 
up, all to pretend to Django that I've got an unbound form, just so I can 
validate its contents.


Another approach to validating an unbound form appears to be to extract 
"value" from the model instance instead of cleaned_data, and this bypasses 
the management form issue, so I'm experimenting with th

Re: APPEND_SLASH skip per URL or per base_uri

[Shai Berger]

On Friday 14 March 2014 17:07:41 Val Neekman wrote:
> Hi Aymeric,
> 
> Localized solution is fine, but when I saw the number posts from people who
> were trying to find a solution to this, I thought, perhaps it would be a
> nice little enhancement to the APPEND_SLASH functionality.
> 

https://github.com/appliedsec/djangular#enforcing-the-end-slashes-of-your-angular-resources

It seems this can be handled adequately from the other side,
and a set of tools for using Django with AngularJS seems like
exactly the right place for such a tool.

So, I don't think this is a good addition to Django core.

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201403191812.58964.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: Saving forms without validation, and formsets

[Chris Wilson]

Hi all,

As part of our test process we have code that automatically fills in forms 
with dummy values to make them valid. It fills in all required fields.


This works well except for formsets. BaseModelFormSet.add_fields() adds a 
PK field to the form after it's created. It marks this field as not 
required:


form.fields[self._pk_field.name] = ModelChoiceField(qs, initial=pk_value, 
required=False, widget=widget)


However it will blow up if editing an existing instance and this field 
isn't present, so in a sense it is required.


I know it's a very minor issue and I can easily work around it (however 
ugly that is), but would it logically make sense for this field to be 
required if pk is not None?


Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Citylife House, Sturton Street, Cambridge, CB1 2QF, UK

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/alpine.OSX.2.00.1403191703550.13253%40chris-macbook.lan.
For more options, visit https://groups.google.com/d/optout.

Re: Saving forms without validation, and formsets

[Carl Meyer]

On 03/19/2014 06:58 AM, Chris Wilson wrote:
>> This requires overrides of a few methods on the parent form: __init__()
>> to create the formsets, is_valid() to ensure the formsets are valid too,
>> has_changed() to see if formsets have changed, and save() to save
>> formsets too.
> 
> There's a few more Form methods that I'm not sure whether I need to
> override, especially if I want to be able to generalise this. I think
> just _get_media and is_multipart should take sub-formsets into account?

Probably so, yeah - I haven't yet ever carried this through into a fully
reusable solution, just implemented it to meet my needs in a specific
case, which apparently never included form media or is-multipart. If
implementing a generic approach you'd want to do a thorough review of
the BaseForm API for places where encapsulated formsets might impact things.

> I think it would be nice for forms to be able to treat embedded formsets
> as a special (complex) type of 'field', so that as_table, as_p etc.
> would render the formsets as well, and for ModelForm to be able to
> generate these automatically for models with ForeignKeys that link back
> to the ModelForm's Model.

I don't use use the shortcut renderings (HTML generated in Python, ick),
so I've never looked into incorporating embedded formsets there.

Having an option to generate embedded formsets for linked models
automatically would be very cool.

I definitely think this idea should get proved out as a third-party app
before we consider it for core.

>>> 3. We couldn't change the "extra" of a formset without redefining the
>>> formset class. We wanted to do this because the required repeating
>>> sections (employment history etc.) must not have a blank form in them if
>>> they already have some valid forms, otherwise the blank forms prevent
>>> the form being submitted because HTML5 client-side validation fails. So
>>> we had to do all this:
>>
>> I don't understand this. The 'extra' attribute of a formset class can be
>> tweaked dynamically as a normal attribute (although this may not be
>> documented); it doesn't require recreating the entire formset class.
> 
> I'm not sure that's possible, because inline_formset defines a new
> class. That class has a class attribute called 'extra' containing the
> value of 'extra', but changing it would change it for all instances of
> the class, so it's not thread-safe. And when the class is instantiated,
> the value is immediately used to create the initial empty forms, and not
> used after that, so changing it after instantiating the form has no
> effect. Thus, it seems that we have to subclass BaseFormSet anyway to
> get into the constructor and change the value of extra before the
> initial forms are created.

That's not quite accurate. The 'extra' attribute on a formset instance
isn't used immediately on instantiation, only lazily when the first
property on the formset is accessed that causes it to create all its
form instances. So there is a window immediately after instantiation
when it is safe and effective to set a different value for 'extra'
directly on the formset instance (not on the class, as you note). Or it
can be done in `__init__` of a BaseFormSet subclass (as you also note).
I think both of those approaches are easier/nicer than creating a whole
new formset class each time you need a different value for 'extra'.

To be clear, here's what I'm currently doing in a project:

class ConditionalExtraInlineFormset(BaseInlineFormSet):
"""Inline formset that adds one extra form if there are no initial
forms."""
def __init__(self, *a, **kw):
super(ConditionalExtraInlineFormset, self).__init__(*a, **kw)
self.extra = 0 if self.initial_form_count() else 1

But if you don't want to subclass for some reason, it would work just as
well to do the same thing from outside the instance, right after it is
instantiated.

>> I snipped your last three items, regarding saving invalid forms. I
>> think this is an unusual use case, and I'm not sure support for it
>> belongs in core. It would be interesting to experiment with something
>> to make filefields less painful when validation fails, but that can be
>> a third-party project first I think.
> 
> It may be unusual, but I'm not the only one to want this. At least two
> people participated on this SO question:
> http://stackoverflow.com/questions/8993749/transform-an-unbound-form-to-a-bound-one
> 
> From there I got my current approach, which is to use model_to_dict to
> create a fake 'data' to make the unbound form bound, so that I can
> validate it. However this is ugly, and it doesn't work with formsets
> because it doesn't account for the management form, which complains
> about having been tampered with because its data is missing. And there's
> no form_to_dict equivalent of model_to_dict, so I'd have to hack
> something up, all to pretend to Django that I've got an unbound form,
> just so I can validate its contents.
> 
> Another approach to valid

Re: [GSOC] Introduction and task proposal

[Daniel Pyrathon]

Hi!

Thanks for all the comments yesterday. They really helped me make the 
proposal stronger.
I have changed to proposal to reflect the changes. Would anyone like to 
have a look and, possibly, comment more?

https://docs.google.com/document/d/1yp2_skqkxyrc0egdRv6ofnRGCI9nmvxDFBkCXgy0Jwo/edit#heading=h.wyxx4xxijubt

Thanks,
Dan

On Wednesday, March 19, 2014 7:32:10 AM UTC, Aymeric Augustin wrote:
>
> On 19 mars 2014, at 06:27, Zach Borboa > 
> wrote: 
>
> > Curious, how do you get REPL shell access to the server with DEBUG=True 
> with a vanilla Django deployment? 
>
> That part of the discussion was about adding the werkzeug interactive 
> debugger to Django’s default error page. 
>
> -- 
> Aymeric. 
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/16264cb7-3f44-434d-865a-8c33baa4d921%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[GSOC] A Library For Integrating Neo4j With Django's ORM

[Saurabh Wahile]

Hello,
I am a third year Computer Engineering B.E student at Mumbai University, 
India. I have 4 years of experience in C++/Java Programming and 1 year in 
Python programming. Coming from a C++/Java background, I appreciate the 
rapid development quality of Python and Django's amazing way of leveraging 
it. Some of the projects that I've previously worked on are here: 
http://saurabhdiaries.tk/?cat=8

*The Problem:*
For the past year, I've been working on a social app for android which 
requires a RESTful API. This I implemented using Django and the tastypie 
library. However, as all social apps require a 'friends'/'relationships' 
module, I was stuck using a foreign key relationship model. This I found to 
be quite counter intuitive and simply wrong to go with as the join 
computation is too heavy on the database. SQL databases are quite good at 
handling large amounts of data but are not designed to handle relationships 
quite well. While researching more, I found out about NoSQL solutions, in 
particular, Neo4j. Neo4j can handle relationships quite well. However while 
digging through a large chunks of data, particularly searching, goes heavy 
on the NoSQL databases, at least for now.  

*The Solution:*
I found out that if i assign storage of linear data to ORM databases and 
the relationships to NoSQL solutions, I would be able to maximize on 
performance and create a 'best-of-both' scenario for developing Django 
applications that rely on heavy data and relationships.

*The Plan:*
I intend to build a library that can help to resolve this issue by using 
Django's existing model architecture and extending the foreign key 
relationships to be redirected onto the NoSQL solution.

I would like to hear any suggestions and if instead of a library, I could 
directly add models fields that could support NoSQL funtionalities.

Awaiting feedback,
Saurabh

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/842f73e4-4c7d-4e5a-8034-ad17df990d8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] A Library For Integrating Neo4j With Django's ORM

[Kirby, Chaim [BSD] - PED]

Hi Saurabh,
On 03/19/2014 03:12 PM, Saurabh Wahile wrote:
Hello,
I am a third year Computer Engineering B.E student at Mumbai University, India. 
I have 4 years of experience in C++/Java Programming and 1 year in Python 
programming. Coming from a C++/Java background, I appreciate the rapid 
development quality of Python and Django's amazing way of leveraging it. Some 
of the projects that I've previously worked on are here:
http://saurabhdiaries.tk/?cat=8

The Problem:
For the past year, I've been working on a social app for android which requires 
a RESTful API. This I implemented using Django and the tastypie library. 
However, as all social apps require a 'friends'/'relationships' module, I was 
stuck using a foreign key relationship model. This I found to be quite counter 
intuitive and simply wrong to go with as the join computation is too heavy on 
the database. SQL databases are quite good at handling large amounts of data 
but are not designed to handle relationships quite well.
"SQL" databases are actually RDBMS - Relational Database management system. 
Above anything else they are built to handle relationships. Not sure why you 
find it counterintuitive, as a ForeignKey is basically the canonical example of 
a relationship. Do you have any statistics to back up "the join computation is 
too heavy on the database", or is this a premature optimization?

While researching more, I found out about NoSQL solutions, in particular, 
Neo4j. Neo4j can handle relationships quite well. However while digging through 
a large chunks of data, particularly searching, goes heavy on the NoSQL 
databases, at least for now.

The Solution:
I found out that if i assign storage of linear data to ORM databases and the 
relationships to NoSQL solutions, I would be able to maximize on performance 
and create a 'best-of-both' scenario for developing Django applications that 
rely on heavy data and relationships.

The Plan:
I intend to build a library that can help to resolve this issue by using 
Django's existing model architecture and extending the foreign key 
relationships to be redirected onto the NoSQL solution.

I would like to hear any suggestions and if instead of a library, I could 
directly add models fields that could support NoSQL funtionalities.

Awaiting feedback,
Saurabh
--
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to 
django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/842f73e4-4c7d-4e5a-8034-ad17df990d8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Regards,
Chaim Kirby


This email is intended only for the use of the individual or entity to which it 
is addressed and may contain information that is privileged and confidential. 
If the reader of this email message is not the intended recipient, you are 
hereby notified that any dissemination, distribution, or copying of this 
communication is prohibited. If you have received this email in error, please 
notify the sender and destroy/delete all copies of the transmittal.

Thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5329FDBD.2060208%40peds.bsd.uchicago.edu.
For more options, visit https://groups.google.com/d/optout.

Re: django.utils.functional.cached_property

[Florian Demmer]

On Thursday, August 8, 2013 6:59:14 PM UTC+2, Łukasz Rekucki wrote:
>
> Hi, 
>
> I have some minor nitpicks: 
>
> 1. Unlike the standard @property, the current implementation of 
> @cached_property doesn't allow for a docstring. 
> 2. Calling `del obj.` before accessing the value 
> or more then once in a row throws an AttributeError. 
>
> Should I make a new ticket for that or just send a PR for the old one ? 
>
>
wow, that AttributeError is super annoying to handle... i'd apprechiate a 
patch for that if you have it already written!

thanks,
Florian 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3cb679f8-78a6-48ac-87d5-0d3102199292%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django.utils.functional.cached_property

[Curtis Maloney]

On 20 March 2014 08:58, Florian Demmer  wrote:

>
>
> On Thursday, August 8, 2013 6:59:14 PM UTC+2, Łukasz Rekucki wrote:
>>
>> Hi,
>>
>> I have some minor nitpicks:
>>
>> 1. Unlike the standard @property, the current implementation of
>> @cached_property doesn't allow for a docstring.
>> 2. Calling `del obj.` before accessing the value
>> or more then once in a row throws an AttributeError.
>>
>> Should I make a new ticket for that or just send a PR for the old one ?
>>
>>
> wow, that AttributeError is super annoying to handle... i'd apprechiate a
> patch for that if you have it already written!
>

How is it behaving any differently to a normal attribute?

I went through this a year or so ago with RKM - once the property is set,
del will clear it, allowing you to affect the call again.  But if it's
unset, del will raise an AttributeError - just like any other attribute.

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSCnEqqgqdrdMmadhc3RAOue2P%2Bv6d4WnK%2B5Eba2Tj7ajA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Introduction and task proposal

[Russell Keith-Magee]

For the benefit of those reading along at home; I gave some revised notes
and had a conversation with Daniel on IRC a couple of hours ago.

Yours,
Russ Magee %-)


On Thu, Mar 20, 2014 at 4:10 AM, Daniel Pyrathon  wrote:

> Hi!
>
> Thanks for all the comments yesterday. They really helped me make the
> proposal stronger.
> I have changed to proposal to reflect the changes. Would anyone like to
> have a look and, possibly, comment more?
>
>
> https://docs.google.com/document/d/1yp2_skqkxyrc0egdRv6ofnRGCI9nmvxDFBkCXgy0Jwo/edit#heading=h.wyxx4xxijubt
>
> Thanks,
> Dan
>
> On Wednesday, March 19, 2014 7:32:10 AM UTC, Aymeric Augustin wrote:
>
>> On 19 mars 2014, at 06:27, Zach Borboa  wrote:
>>
>> > Curious, how do you get REPL shell access to the server with DEBUG=True
>> with a vanilla Django deployment?
>>
>> That part of the discussion was about adding the werkzeug interactive
>> debugger to Django's default error page.
>>
>> --
>> Aymeric.
>>
>>
>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/16264cb7-3f44-434d-865a-8c33baa4d921%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84_pBSmYKX2w-c1JDcAxtPjuwUsxdHstAHJYpZeWhK2DNg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] A Library For Integrating Neo4j With Django's ORM

[Russell Keith-Magee]

Hi Saurabh,

On Thu, Mar 20, 2014 at 4:12 AM, Saurabh Wahile wrote:

> Hello,
> I am a third year Computer Engineering B.E student at Mumbai University,
> India. I have 4 years of experience in C++/Java Programming and 1 year in
> Python programming. Coming from a C++/Java background, I appreciate the
> rapid development quality of Python and Django's amazing way of leveraging
> it. Some of the projects that I've previously worked on are here:
> http://saurabhdiaries.tk/?cat=8
>
> *The Problem:*
> For the past year, I've been working on a social app for android which
> requires a RESTful API. This I implemented using Django and the tastypie
> library. However, as all social apps require a 'friends'/'relationships'
> module, I was stuck using a foreign key relationship model. This I found to
> be quite counter intuitive and simply wrong to go with as the join
> computation is too heavy on the database. SQL databases are quite good at
> handling large amounts of data but are not designed to handle relationships
> quite well. While researching more, I found out about NoSQL solutions, in
> particular, Neo4j. Neo4j can handle relationships quite well. However while
> digging through a large chunks of data, particularly searching, goes heavy
> on the NoSQL databases, at least for now.
>

I don't know if I'd completely agree with the way you've phrased this. SQL
is a query language used to access RDBMSs. The "R" in RDBMS stands for
"Relational", so saying SQL isn't good with relationships is patently
untrue. Unless, of course, you're interpreting "relationship" a particular
way; which if you're using Neo4j (an object database), I suspect you
probably are.

Also - if anyone says "Databases can't handle joins", make sure they're not
using MySQL as their point of reference. MySQL is definitely awful at
joins. However, real databases (by which I mean PostgreSQL, Oracle, etc)
are a whole lot better because they actually know what indexes are, and
have query planners that use them.

*The Solution:*
> I found out that if i assign storage of linear data to ORM databases and
> the relationships to NoSQL solutions, I would be able to maximize on
> performance and create a 'best-of-both' scenario for developing Django
> applications that rely on heavy data and relationships.
>
> *The Plan:*
> I intend to build a library that can help to resolve this issue by using
> Django's existing model architecture and extending the foreign key
> relationships to be redirected onto the NoSQL solution.
>
> I would like to hear any suggestions and if instead of a library, I could
> directly add models fields that could support NoSQL funtionalities.
>

This is a project that is potentially interesting, but is probably going to
be rejected on the basis that it doesn't pay enough attention to prior and
current attempts in the same space.

A few years back, Alex Gaynor did a GSoC project that attempted to write a
NoSQL database backend. He was using MongoDB, and he was able to identify
and clean up a bunch of problems. However, he also hit a couple of brick
walls in the design, and the project was abandoned before it got to trunk.

Fast forward to today, and there is a proposal for *this* GSoC that has
been discussed at length with the aim of producing the formal API and
documentation to make it easier to third-party model layers that will be
compatible with Django's internals. This project has been discussed at
length, and is a quite mature proposal at this point.

You've joined this discussion with less than 3 days remaining in the GSoC
application process, and have provided little more than "I've got an idea".
Even if there wasn't a competing (and much more mature) project, the detail
you've provided here is nowhere near the level we'd expect of a successful
Django GSoC applicant.

There's obviously still time, but there isn't much of it. If you want to be
accepted for this GSoC, you're going to need to put together a full
proposal very quickly. Unfortunately, you're not going to have time for a
whole lot of community feedback.

If you want to proceed, I would suggest by reading up on the prior art that
I've mentioned. At the very least, this will give you an idea of what is
possible, and what approaches to this problem have already been tried.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84-OBopdYJ1vXoU5dAJJNCtOFbygzTKecMoAu_%3Dtj%2B_b9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.