Re: [ GSOC 2016 ] providing standard interface for NoSQL databases

[Anssi Kääriäinen]

There are two goals when it comes to document DB support. First goal
is to allow usage of models written specifically for document oriented
databases. This is something that should be possible to achieve even
if there are some hard problems to solve. The other goal is to allow
usage of any Django model with document oriented databases just like
you would use it with relational databases. This goal is extremely
hard to achieve.

The reason the latter one is hard is that for example ForeignKey and
ManyToManyField do not make much sense with document oriented
databases. In addition most Django models use auto-incrementing
primary keys, and pretty much no distributed database supports those
properly. So, if you take a random Django model (say
django.contrib.auth.models.Permission) it will not be easy to fit that
model into document oriented databases. If I recall correctly, one of
the big problems for the GSoC project Russell mentioned was support
for any Django model with document oriented databases.

I believe there would be lots of uses for models which are written
specifically for document oriented databases. So +1 to the general
idea.

 - Anssi


On Wed, Mar 16, 2016 at 3:10 AM, Russell Keith-Magee
 wrote:
>
> It would also be worthwhile looking into the prior art on this topic. We had
> a GSoC project for non-relational data stores a few years back, and came to
> the conclusion that it probably wasn’t viable. You can dig into the archives
> to find out why.
>
> If you’re interested in adding non-relational support to Django, my
> inclination is that you’ll get more traction proposing a specific backend -
> I outlined what would be involved in my DjangoCon US talk last year:
>
> https://www.youtube.com/watch?v=VgM0qmpHDiE
>
> Yours,
> Russ Magee %-)
>
> On Wed, Mar 16, 2016 at 5:50 AM, Curtis Maloney  wrote:
>>
>> It sounds like by "NoSQL DBS" you mean specifically "Document store DBMS".
>> Is this correct?
>>
>> (I'm sure most people know my rant about how "NoSQL" is a misnomer, and
>> it's really "Non-relational" that people mean - it's not SQL per se they're
>> avoiding, it's the relational model)
>>
>> The NoSQL/Non-rel name is really too vague, as it covers "anything that's
>> not SQL / Relational"... which can cover key/value, document, graph, log,
>> and even filesystem or email, when it comes down to it.
>>
>> I think it will help if you clarify what model you _do_ target, not which
>> you do _not_.
>>
>> All that said/vented, I agree it would be nice to have a common
>> abstraction layer atop various document stores.  The trick now will be
>> finding sufficient commonalities.
>>
>> I feel that the ORM's relation-span/transforms/lookups syntax would be
>> equally viable on nested documents.
>>
>> One of the benefits of an abstraction layer is allowing other tools to
>> generically interact with these new objects.  What plans do you have for how
>> to support non-flat documents in, for instance, Forms?
>>
>>
>> --
>> Curtis
>>
>> On 16/03/16 05:29, girish ramnani wrote:
>>>
>>>
>>> Hello,
>>>
>>> I would like to propose providing a standard interface for NoSQL
>>> databases . Some the points to consider are:
>>>
>>>  1. The /Fields /which are used to define the schema of the sql
>>> databases can also be used to provide in No sql databases.
>>>  2. In NoSQL dbs ,developers usually store data in denormalized form. so
>>> in two related collections a meta tag /denormal = True /can be
>>> provided. Which would make that collection a child of the other
>>> model ( related ). In normal scenario the collections will be
>>> connected using _id used as a foreign key.
>>>  3. providing contrib.mongo with Field such as GridFSField for providing
>>> support for GridFS
>>>  4. considering the database transaction transaction blocking ( PyMongo
>>> provides blocking api for mongo )
>>>  5. creating Mixins such as /FlexibleMixin /which would allow Models to
>>> have dynamic fields. i.e directly insert fields which are not listed
>>> in the Model schema.
>>>
>>>
>>> there are lot more things (Migrations, settings etc) to consider but
>>> before that needed to know that I am going in the right direction or
>>> not?. Please suggest.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>>
>>> https://groups.google.com/d/msgid/django-developers/b2477318-9252-4241-a9fe-0972acb1b1cf%40googlegroups.com
>>>
>>> 

Re: Bringing some popular must have django tools/packages under django org umbrella

[James Pic]

Sorry for to quoting:/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KaeqUamDV0PLOu4f0bW%2BpTyqV5B%3Dj6EwF_715pvuwkJ0Pg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bringing some popular must have django tools/packages under django org umbrella

[James Pic]

What do you mean stuck? Aren't you supposed to port the packages and submit
a patch in that case? How are you stuck ? I know the first portings are
hard but once you've ported a dozen it becomes piece of cake so don't be
afraid of trying ! And please contribute to the apps !!

I know some people who only open issues and never submit a patch on github,
isn't that super annoying?
On Mar 16, 2016 5:38 AM, "Matías Iturburu"  wrote:

> I recently got stuck upgrading a project to 1.9 due to a lot of useful
> packages being not maintained:
>
> - django-endless-pagination: a substitute for django-pagination while it
> didn't had python3 support
> - django-taggit-templatetags: from when django-tagging didn't had python3
> support.
>
> django-registration was another must have that recently resurfaced but the
> same situation spawned django-registration-redux.
>
> Would it be too much a hassle to open an django-contrib organization with
> less friction provide support for orphaned projects?
>
> 2015-11-24 16:27 GMT-03:00 Marc Tamlyn :
>
>> This is something the core team discussed in Amsterdam. I believe there
>> was consensus to trial it with Django registration. I should catch up with
>> James and see if it is transferred. If this goes well I see no reason why
>> not.
>>
>> The biggest problem is the selection of packages, we have historically
>> wanted to avoid too much bikeshedding. Initially it's likely to be mostly
>> relatively inactive small utilities I think. But I think we are open to
>> being more risky here.
>>
>> M
>> On 24 Nov 2015 7:02 pm, "Asif Saifuddin"  wrote:
>>
>>> The projects will have the official tool status + the maintainer of the
>>> projects will be able to collaborate better with django core team? less
>>> risk of being abandoned by the maintainers etc.
>>>
>>> IMHO
>>>
>>> On Wed, Nov 25, 2015 at 12:31 AM, Collin Anderson 
>>> wrote:
>>>
 Hi,

 Say a little bit more: What would be the goal? What would you hope
 would be accomplished by doing this?

 Thanks,
 Collin

 On Tuesday, November 24, 2015 at 1:27:11 PM UTC-5, Asif Saifuddin wrote:
>
> How is the idea? tools like django-debug-toolbar, django-silk,
> django-taggit, django-filter etc and some more de facto tools under the
> umbrella of django github org?
>
> Regards
>
 --
 You received this message because you are subscribed to a topic in the
 Google Groups "Django developers (Contributions to Django itself)" group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/django-developers/bIzfHebE2sw/unsubscribe
 .
 To unsubscribe from this group and all its topics, 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/70062405-3ccd-49b2-9118-ec1679203cd1%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 (Contributions to Django itself)" 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/CAKAqTgrnMoqy-%3DdDUx31Dgru6XTzT3e-T%3DhspY-CDK5tV9k1gQ%40mail.gmail.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 (Contributions to Django itself)" 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/CAMwjO1FzQ8cCgF7pR%2BRtPiSkNc5W4ipeWfwLz0hi4q_xzxZoAQ%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com