Re: Integrating Django with Tornado's web server

[girish ramnani]

Hi Bastin,
 I know you addressed the question to bret, but i would like to suggest 
what i did , i actually used gevent-socketio with the pywsgi server .
I did it a while ago so dont know if things are the same. If you find 
something better then do tell.

On Wednesday, October 21, 2015 at 4:52:23 PM UTC+5:30, Bastin Robins J 
wrote:
>
> Hi Bret,
>
> We have built our app using django 1.7 and we need to implement websockets 
> for some async purpose. So thought tornado would suit our need
> Can you tell me a best practice to achieve this.
>
> On Monday, September 14, 2009 at 2:00:59 AM UTC+5:30, Bret Taylor wrote:
>>
>> I am one of the authors of Tornado (http://www.tornadoweb.org/), the 
>> web server/framework we built at FriendFeed that we open sourced last 
>> week (see http://bret.appspot.com/entry/tornado-web-server). 
>>
>> I just checked in change to Tornado that enables you to run any WSGI- 
>> compatible framework on Tornado's HTTP server so that Django apps 
>> could run on top of Tornado's HTTP server and benefit from some of the 
>> performance work we have done. (I just sent a message to django-users@ 
>> with getting started instructions as well, but if you are interested, 
>> take a look at 
>> http://github.com/facebook/tornado/blob/master/tornado/wsgi.py#L188). 
>>
>> I chose the WSGI approach because it is generic and applies to all 
>> frameworks, but Django is obviously the most widely used. I am curious 
>> if there is any benefit to implementing more "native" support in 
>> django.core.handlers or if WSGI is the preferred way of adding support 
>> for new servers. If there is any performance or usability benefit, let 
>> me know, because we would be happy to contribute our time to make it 
>> happen. 
>>
>> In the meantime, if you find any issues with our WSGI support, let me 
>> know so we can fix problems. 
>>
>> Bret 
>>
>

-- 
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/04f525f0-e376-496c-b8d1-d304b1a2a0dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ GSOC 2016 ] providing standard interface for NoSQL databases

[girish ramnani]

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.
For more options, visit https://groups.google.com/d/optout.

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

[girish ramnani]

In the beginning I thought about making an api which supports column 
databases such as cassendra but would mean that i would need to first find 
commonalities between all 3 ( column , document and relational ) but such 
commonalities would be lesser and so finally i would require to create a 
separate api instead of trying to provide it with db.Model.

So i will be target only document based databases like mongo , rethink etc.

There is an opinion I seek from the community.

1 ) Providing a separate Model written specifically for document database 
would provide easier addition of new features related to real time 
capabilities which could be used after ASGI gets merged. Also a developer 
usually knows before writing any code which type of database (relational or 
non-relational ) so in my opinion there wouldn't be developers who would 
use sqlite in dev mode and then change it to mongo in production. So would 
it be better to provide a separate Model for document databases ?

2 ) On the other hand , using the db.Model will be easier to use as the api 
is already familiar with the developers but using the same api suggests a 
certain level of similarity between databases which cant be seen in case of 
relational and document databases. 
  
So would the community be open to adding a seperate Model class eg. 
DocumentModel or Collection .

There are alot of problems which are to be address ( some mentioned by Anssi 
Kääriäinen ).

The multiple database support,Forms,migrations,Meta,django admin , django 
auth etc. I would try to address the problems in my proposal as in-depth as 
possible. 


On Wednesday, March 16, 2016 at 3:20:25 AM UTC+5:30, 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-develop...@googlegroups.com  
> > <mailto:django-developers+unsubscr...@googlegroups.com >. 
> > To post to this group, send email to django-d...@googlegroups.com 
>  
> > <mailto:django-d...@googlegroups.com >. 
> > Visit this group at https://groups.google

[ GSOC 2016 ] Proposal for template profiling and optimization

[girish ramnani]

After reading through the db source code of django I realized the 
complexity of adding a standard interface for NoSQL column database, and i 
realized that it will require more than summer (for me). Also the changes 
in the framework were affecting many parts such as migrations,meta ,forms 
etc . So i dropped that idea. But i would like to contribute to django by 
profiling and bench-marking templates to find the bottle necks in the 
engine which can be optimized.

*Here *is my 
GSOC proposal
*. *

-- 
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/f963f7e0-0f38-42fb-86bd-005ee4ee91b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ GSOC 2016 ] Proposal for template profiling and optimization

[girish ramnani]

I am really sorry to the community. 

-- 
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/7d314c7f-652d-42bf-b03c-c4d62fd72ee0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.