Re: Having a MongoDB connector for Django

[Nes Dis]

Hello

I would like to add that the application level joins are scripted such that 
they are *atomic in nature. *Which means if there is another thread/process 
operating in parallel, It will have no impact on final output. Is this why 
you feel an application join is scary?

Regards
Nes Dis

On Friday, 8 September 2017 18:33:59 UTC+5:30, Nes Dis wrote:
>
> Hello
>
> I am wondering what is the state of the art on Django having a backend 
> connector for MongoDB database backend. There are a few solutions out there 
> but they don't work as expected. 
>
> A possible solution for this is to have a connector which translates SQL 
> queries created in Django, into MongoDB queries.
>
> I would like to hear the *expert opinion *from the esteemed members of 
> this group on this concept.
>
> A working solution for this can be found here: djongo 
> . (Django + Mongo = Djongo) The project 
> is hosted on github.
>
> Regards
> Nes Dis
>

-- 
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/5252cca0-90f4-42d2-9b10-333f2a44ccd2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tim Graham]

Hi,

Tom got sick and hasn't been able to work on the documentation as he'd 
hoped. If anyone wants to help, I left some TODOs (denoted by XXX) on the 
pull request: https://github.com/django/django/pull/9072. I'll be offline 
tomorrow morning (EDT) but I hope to resume work on it around 1700 UTC 
tomorrow. Anyone else is welcome to contribute until then (or even after 
that... I can always work on other things). Just coordinate here so we 
don't duplicate effort.

I've spent most of the past two days doing cleanup on the corresponding 
code changes (https://github.com/django/django/pull/7482). I don't have any 
big todos remaining there besides giving it a review for cosmetic 
improvements.

Thanks!

On Wednesday, September 13, 2017 at 4:17:22 PM UTC-4, Sjoerd Job Postmus 
wrote:
>
> Hi all,
>
> I have not mentioned this so far in public channels. However, I will not 
> really able to spend a lot of time on this PR for the upcoming days due to 
> my son's birthday coming up this Saturday.
>
> I will keep an eye on the pull request and comments, and reply to the best 
> of my ability.
>
> Thank you all for the willingness to push this forward at the last minute, 
> but I can understand if it is a bit too much to handle in a short timeframe.
>
> If after this weekend there is more work that needs to be done, I'll 
> happily put in the effort.
>
> Kind regards,
> Sjoerd Job
>
> On 13 Sep 2017 9:19, Tim Graham  wrote:
>
> Okay, I'll work on the patch and make it my top priority.
>
> On Wednesday, September 13, 2017 at 1:54:00 PM UTC-4, Claude Paroz wrote:
>
>
> Perhaps we can find a compromise to ship this feature in the alpha with 
> minimal docs and complete the docs later?
>
>
> I'm in favour.
>
> Claude 
>
> -- 
> 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 .
> To post to this group, send email to django-d...@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/ada721d9-50f9-42e8-97eb-d4fbb073bddf%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a0d798b3-2177-433b-a1fb-253ca1b0442e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Having a MongoDB connector for Django

[Tom Forbes]

You're right for pointing out that some elements of a relational database
can be emulated in a non relational one, like Mongodb. The in-python joins
sound s bit scary though.

However I would argue that if you find yourself needing such things your
data is relational, and therefore a relational database is perhaps a better
fit than a non relational one.

On 15 Sep 2017 18:44, "Nes Dis"  wrote:

I would like to thank everyone for their valuable comments. Simultaneously
I would like to comment on some conceptions regarding using MongoDB. Its
not accurate to state that relational joins cannot happen in MongoDB. It
can be done at the application level. LEFT JOIN and INNER JOIN. A detailed
description
 of this
is available.

Admin modules rely heavily on SQL, So cannot be ported to MongoDB. But
admin porting to MongoDB is working successfully in djongo.

Regards
Nes Dis


On Friday, 8 September 2017 18:33:59 UTC+5:30, Nes Dis wrote:

> Hello
>
> I am wondering what is the state of the art on Django having a backend
> connector for MongoDB database backend. There are a few solutions out there
> but they don't work as expected.
>
> A possible solution for this is to have a connector which translates SQL
> queries created in Django, into MongoDB queries.
>
> I would like to hear the *expert opinion *from the esteemed members of
> this group on this concept.
>
> A working solution for this can be found here: djongo
> . (Django + Mongo = Djongo) The project
> is hosted on github.
>
> Regards
> Nes Dis
>
-- 
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/e0ac0919-0ae6-4a42-ba7c-c558bc42d141%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFNZOJP1GNXO_7%3Di5NdqL-gqvtGMdi6UCyD6W1BB79u72wTmRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Having a MongoDB connector for Django

[Nes Dis]

I would like to thank everyone for their valuable comments. Simultaneously 
I would like to comment on some conceptions regarding using MongoDB. Its 
not accurate to state that relational joins cannot happen in MongoDB. It 
can be done at the application level. LEFT JOIN and INNER JOIN. A detailed 
description 
 of this 
is available.

Admin modules rely heavily on SQL, So cannot be ported to MongoDB. But 
admin porting to MongoDB is working successfully in djongo.

Regards
Nes Dis

On Friday, 8 September 2017 18:33:59 UTC+5:30, Nes Dis wrote:
>
> Hello
>
> I am wondering what is the state of the art on Django having a backend 
> connector for MongoDB database backend. There are a few solutions out there 
> but they don't work as expected. 
>
> A possible solution for this is to have a connector which translates SQL 
> queries created in Django, into MongoDB queries.
>
> I would like to hear the *expert opinion *from the esteemed members of 
> this group on this concept.
>
> A working solution for this can be found here: djongo 
> . (Django + Mongo = Djongo) The project 
> is hosted on github.
>
> Regards
> Nes Dis
>

-- 
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/e0ac0919-0ae6-4a42-ba7c-c558bc42d141%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecating CachedStaticFilesStorage in Django 2.0

[Tim Graham]

About the timing, it's too late to get this in to Django 2.0 as the feature 
freeze is on Monday and I already have a large queue of review work to do 
before then. I don't think it makes much difference since features 
deprecated in both Django 2.0 and 2.1 will be removed in Django 3.0.

On Friday, September 15, 2017 at 12:58:44 PM UTC-4, emo...@mozilla.com 
wrote:
>
> Hi!
>
> Currently when using `ManifestStaticFilesStorage`, collectstatic generates 
> duplicate versions of some files. For example looking at the output for 
> contrib.admin for Django 1.11.5, there is:
> - admin/css/base.css
> - admin/css/base.5af66c1b1797.css
> - admin/css/base.6b517d0d5813.css
> - admin/css/base.31652d31b392.css
>
> This is exacerbated when using something like WhiteNoise's 
> CompressedStaticFilesMixin, 
> which then has to spend extra time generating gzip and Brotli compressed 
> versions of every file (or else try and work around it).
>
> I was going to file a ticket about fixing this, however it appears to be 
> unavoidable/working as intended according to:
> https://code.djangoproject.com/ticket/24452#comment:16
>
> In that ticket and corresponding PR, it's mentioned several times that 
> CachedStaticFilesStorage is suboptimal and should probably be removed, and 
> if that occurred it would then be possible to avoid the duplication.
>
> As such, I'd like to propose that `CachedStaticFilesStorage` be marked as 
> deprecated for the Django 2.0 release (with the warning suggesting people 
> use `ManifestStaticFilesStorage` instead), so we could then remove it and 
> make these optimisations in Django 3.0.
>
> Thoughts?
>
> Many thanks,
>
> Ed
>

-- 
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/9e875088-6647-4923-a53f-bd97d20262c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecating CachedStaticFilesStorage in Django 2.0

[Adam Johnson]

(For some reason GMail is clipping your message before any content, I only
saw '... [Message clipped]' and had to click to see it all)

I'm not that familiar with the static file storages, but it seems to me
like it's not going to be that controversial deprecate it in order to save
this duplication. The docs do read:

CachedStaticFilesStorage isn’t recommended – in almost all cases
> ManifestStaticFilesStorage is a better choice.


On 15 September 2017 at 17:58,  wrote:

> Hi!
>
> Currently when using `ManifestStaticFilesStorage`, collectstatic generates
> duplicate versions of some files. For example looking at the output for
> contrib.admin for Django 1.11.5, there is:
> - admin/css/base.css
> - admin/css/base.5af66c1b1797.css
> - admin/css/base.6b517d0d5813.css
> - admin/css/base.31652d31b392.css
>
> This is exacerbated when using something like WhiteNoise's 
> CompressedStaticFilesMixin,
> which then has to spend extra time generating gzip and Brotli compressed
> versions of every file (or else try and work around it).
>
> I was going to file a ticket about fixing this, however it appears to be
> unavoidable/working as intended according to:
> https://code.djangoproject.com/ticket/24452#comment:16
>
> In that ticket and corresponding PR, it's mentioned several times that
> CachedStaticFilesStorage is suboptimal and should probably be removed, and
> if that occurred it would then be possible to avoid the duplication.
>
> As such, I'd like to propose that `CachedStaticFilesStorage` be marked as
> deprecated for the Django 2.0 release (with the warning suggesting people
> use `ManifestStaticFilesStorage` instead), so we could then remove it and
> make these optimisations in Django 3.0.
>
> Thoughts?
>
> Many thanks,
>
> Ed
>
> --
> 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/b5a12c9b-ab4b-4431-b633-
> 43a0ddfdd534%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM3q9DgEqMNV%3DtwU%2BajbzodOZnyeTH_h%3DnQbjE0n4DK3LQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database "execute hooks" for instrumentation

[Shai Berger]

On Friday 15 September 2017 11:35:49 Shai Berger wrote:
> On Friday 15 September 2017 11:09:58 Anssi Kääriäinen wrote:
> > 
> > def simple_execute_hook(execute):
> > # One-time configuration and initialization.
> > 
> > def execute_hook(sql, params, many, context):
> > # Code to be executed for each cursor.execute() call.
> > # If many = True, the final call will be execute_many.
> > # The context parameter might contain stuff like used
> > # connection.
> > execute(sql, params, many, context)
> > # Code to be executed after the SQL has been ran.
> > 
> > return execute_hook
> > 
> > You would then add the hook with the connection's context manager.
> > 
> > The reason I'm asking is that this way the coding style would be
> > immediately familiar if you have used the request/response middlewares.
> 
> That's an interesting suggestion. At first look, it seems a nicer API than
> the context manager. I'm a little worried about how errors would be
> handled, though.

Well, of course, error handling was a red herring. It's up to the hook author.

But while looking deeper into it, I noted something else: The "One time 
configuration" part doesn't really make sense. I'll explain:

Since the `execute` argument is really a method on a cursor object which, 
potentially, doesn't even exist when the hook is installed, it needs to be 
passed into simple_execute_hook() near invocation time, rather than at 
registration time; and in fact, within the scope of one hook registration, we 
may need to handle separate cursors. So, the external function must be called 
again for every execution. Thus, the difference between code in the "one time 
configuration" (actually, "each time configuration") part and code in the "code 
to execute before query" part becomes arcane and hard to explain.

So, it becomes much more sensible to turn the hook into a wrapper, defined as:

def execute_wrapper(execute, sql, params, many, context):
# Code to be executed for each cursor.execute() call.
# If many = True, the final call will be execute_many.
# The context parameter might contain stuff like used
# connection.
result = execute(sql, params, many, context)
# Code to be executed after the SQL has been ran.
return result

Or even:

def execute_wrapper(execute, sql, params, many, context):
try:
# Code to be executed for each cursor.execute() call.
return execute(sql, params, many, context)
finally:
# Code to be executed after the SQL has been ran.

For this, I just need to figure out the currying of the execute parameter.

Shai

Re: Having a MongoDB connector for Django

[Santiago Fraire Willemoës]

I agree with everyone, no relation with relational should not be mixed 
because they solve different problems.
On the other hand, having an Object Document Manager (instead of an ORM) if 
required could be a possibility, right? 
I think until a lot of people have that need, it won't happen. 
I've used https://github.com/MongoEngine/mongoengine and it felt like using 
django's ORM

Regards,
Santiago

El viernes, 8 de septiembre de 2017, 15:03:59 (UTC+2), Nes Dis escribió:
>
> Hello
>
> I am wondering what is the state of the art on Django having a backend 
> connector for MongoDB database backend. There are a few solutions out there 
> but they don't work as expected. 
>
> A possible solution for this is to have a connector which translates SQL 
> queries created in Django, into MongoDB queries.
>
> I would like to hear the *expert opinion *from the esteemed members of 
> this group on this concept.
>
> A working solution for this can be found here: djongo 
> . (Django + Mongo = Djongo) The project 
> is hosted on github.
>
> Regards
> Nes Dis
>

-- 
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/abf9e9d0-d6ac-48fd-8e33-8302a1216130%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database "execute hooks" for instrumentation

[Shai Berger]

On Friday 15 September 2017 11:09:58 Anssi Kääriäinen wrote:
> Would it make sense to use the same technique used for HTTP
> request/response middleware? That is, the hook would look a bit like this:
> 
> def simple_execute_hook(execute):
> # One-time configuration and initialization.
> def execute_hook(sql, params, many, context):
> # Code to be executed for each cursor.execute() call.
> # If many = True, the final call will be execute_many.
> # The context parameter might contain stuff like used
> # connection.
> execute(sql, params, many, context)
> # Code to be executed after the SQL has been ran.
> return execute_hook
> 
> You would then add the hook with the connection's context manager.
> 
> The reason I'm asking is that this way the coding style would be
> immediately familiar if you have used the request/response middlewares.
> 

That's an interesting suggestion. At first look, it seems a nicer API than the 
context manager. I'm a little worried about how errors would be handled, 
though.

Re: Database "execute hooks" for instrumentation

[Anssi Kääriäinen]

Would it make sense to use the same technique used for HTTP request/response 
middleware? That is, the hook would look a bit like this:

def simple_execute_hook(execute):
# One-time configuration and initialization.
def execute_hook(sql, params, many, context):
# Code to be executed for each cursor.execute() call.
# If many = True, the final call will be execute_many.
# The context parameter might contain stuff like used
# connection.
execute(sql, params, many, context)
# Code to be executed after the SQL has been ran.
return execute_hook

You would then add the hook with the connection's context manager.

The reason I'm asking is that this way the coding style would be immediately 
familiar if you have used the request/response middlewares.

 - Anssi

-- 
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/e6098f14-0f0a-4ae6-b094-bfd9e2ccb51a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.