Re: Weird messages in my console

[Vineet Kothari]

As admin is abstracted a lot how will you able to make out man. Try to
understand find these name by doing find all then maybe if some print
statement is outputting them you may find it.

On Fri 26 Oct, 2018, 10:00 PM Mark Phillips, 
wrote:

> I am building a django 2.0 application, and I have noticed some strange
> output in my console when I use runserver. I use logging a lot to follow
> what is happening in my code as I write it, so there are a lot of logging
> messages in the console. However, these weird messages do not have the same
> format as the logging messages.
>
> normal log message:
> [2018-10-26 09:16:38] DEBUG [memorabilia.admin.search_metadata:86]
> search_metadata END - , Document
>
> weird messages:
> date_hierarchy cl=%s created
> link=%s ?
> link=%s ?created__month=5__year=2018
> link=%s ?created__month=6__year=2018
> link=%s ?created__month=10__year=2018
>
> From the flow in the console messages, they come from one of my Admin
> classes. I cannot find anything like these messages in that Admin class. At
> first, I thought they were some old print statements left over before I
> started using logging, but I have grep'ed for any print statements in my
> entire code base, and there are not any. They look a little like urls, but
> there are not print statements in my urls.py files. I also grep'ed for
> parts of these strings and the whole strings, and they are not in any of my
> files.
>
> I am stumped on how to track down these strange messages.
>
> Thanks for any help you can provide!
>
> Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAEqej2P2MTKFTLk%2Bs8LSAmPCpAWwb%3DMAzP47Xc9iL_oPyiEvmQ%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAAcansvXktS5gj9aNE0LkWRV_1pc0%3DFUCow031hvPVE%2BNCqbFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django to serve JSON: overkill?

[Vineet Kothari]

You can use falcon/flask if you only want to create api as these are
minimalistic frameworks and very easy to understand

On Mon 29 Oct, 2018, 4:45 AM PASCUAL Eric,  wrote:

> Hi Charley,
>
>
> You should not regret this choice.
>
> Sometimes Django seems a bit overkill at the first glance. But most of the
> times, once the project has made some progress you'll quickly appreciate
> the fact it is like Python : batteries included. No need to hunt for
> external add-ons which will integrate more or less easily when it comes to
> take care of CORS, CSRF, sessions, I18N,... All is already here for free. I
> could verify this on a Flask based project : you're left alone when time
> comes for you to find the right LEGO blocks and make then fit together.
> Django creators have already made this for you, and they're very smart
> people.
>
>
> And of course the default Django configuration can be optimized by
> removing middlewares and features you don't need to cut it down to the
> strict necessary. So, why bother ?
>
>
> Regards
>
>
> Eric
> --
> *From:* django-users@googlegroups.com  on
> behalf of Charley Paulus 
> *Sent:* Sunday, October 28, 2018 2:53:04 PM
> *To:* Django users
> *Subject:* Re: Django to serve JSON: overkill?
>
> Hi Eric,
>
> Yes that helps a lot.
> I have data models and related DB.
> I’ll go with Django.
>
> Thanks.
>
> Best regards,
> Charley
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/77c35a21-591d-41e5-8bd5-4314a5b0614d%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 users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/VI1P193MB04325B2D1B8CF0A98E5C3C2A8CF20%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Django to serve JSON: overkill?

[PASCUAL Eric]

Hi Charley,


You should not regret this choice.

Sometimes Django seems a bit overkill at the first glance. But most of the 
times, once the project has made some progress you'll quickly appreciate the 
fact it is like Python : batteries included. No need to hunt for external 
add-ons which will integrate more or less easily when it comes to take care of 
CORS, CSRF, sessions, I18N,... All is already here for free. I could verify 
this on a Flask based project : you're left alone when time comes for you to 
find the right LEGO blocks and make then fit together. Django creators have 
already made this for you, and they're very smart people.


And of course the default Django configuration can be optimized by removing 
middlewares and features you don't need to cut it down to the strict necessary. 
So, why bother ?


Regards


Eric


From: django-users@googlegroups.com  on behalf 
of Charley Paulus 
Sent: Sunday, October 28, 2018 2:53:04 PM
To: Django users
Subject: Re: Django to serve JSON: overkill?

Hi Eric,

Yes that helps a lot.
I have data models and related DB.
I’ll go with Django.

Thanks.

Best regards,
Charley

--
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/77c35a21-591d-41e5-8bd5-4314a5b0614d%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/VI1P193MB04325B2D1B8CF0A98E5C3C2A8CF20%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM.
For more options, visit https://groups.google.com/d/optout.

Re: Django to serve JSON: overkill?

[Charley Paulus]

Hi Eric,

Yes that helps a lot.
I have data models and related DB.
I’ll go with Django.

Thanks.

Best regards,
Charley

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/77c35a21-591d-41e5-8bd5-4314a5b0614d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Celery/Redis Django 2.0 Design Question

[hunter.cur...@gmail.com]

I think you are on the right track. I am doing something similar with 
photos and gps tracks uploaded by users and the celery/redis combo makes it 
easy to run a compute intensive task without blocking the site.
I'm not sure if the celery-signals approach is strictly necessary, 
however.  I am following the architecture laid out in cookiecutter-django  
(using docker) where the 
celery container is a copy of the django container.
That way, when the transformations are complete, the celery task can just 
issue a django style create or update command to access the database.

Good luck!
dave

On Saturday, October 27, 2018 at 6:13:19 PM UTC-6, mark wrote:
>
> I am building a django 2.x site to:
> * upload documents (images, pdfs, and videos)
> * apply metadata to the documents (JSON metadata field)
> * transform the documents (thumbnails, OCR, language translations, image 
> conversion, facial recognition, image blurring, etc.) based on some of the 
> metadata fields
> * display the documents
>
> Since the document transformations are fairly resource intensive and time 
> consuming, I am thinking of using celery to build a state machine for the 
> transformations, using celery tasks to transform the images, and celery 
> signals to update the state of the document as the transformations complete 
> successfully. I looked at django-fsm for this, but I think it will be 
> better to run the transformations as celery tasks than to block the site. 
>
> Does this plan make sense, or am I missing something regarding django and 
> celery/redis.
>
> Thanks!
>
> Mark
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/70a447cf-312a-42dd-9eaf-24db3ef238b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should I use Django-Rest-Framework for performance reasons, despite not needing an externally-consumable API?

[PASCUAL Eric]

Hi,


Do you think there's any reason to use DRF despite not needing an 
externally-consumable API?

None that I can think about. But I don't pretend to be an expert on the topic ;)


IMHO it is just a matter of planing for the future. If you are certain that 
nothing else but your current app will need to play with the models, adding a 
REST API (be it written on top of DRF or not) is not required at all. To my 
knowledge it will not bring any benefit WRT performances. Chances are that it 
will be the opposite (but not in dramatic proportions however if the underlying 
stack is properly chosen and configured) since the REST API adds a layer of 
HTTP based exchanges.


Regards


Eric


From: django-users@googlegroups.com  on behalf 
of Tyler Lynch 
Sent: Saturday, October 27, 2018 7:12:13 PM
To: Django users
Subject: Re: Should I use Django-Rest-Framework for performance reasons, 
despite not needing an externally-consumable API?

Hey Eric, thanks for getting back to me again!

As I don't want to have an externally-consumable API for this application 
(would be more of a liability than asset for me right now), I am most likely 
going to not use DRF.

I know it'll be more time-consuming refactoring if I ever do decide to use DRF, 
but I'm okay deferring this decision for now.

Do you think there's any reason to use DRF despite not needing an 
externally-consumable API? Would using an internally-consumed API have 
different benefits? It seems the consensus is that adding DRF is more likely to 
limit performance than enhance, as you suggested earlier.

Regards,
Tyler


On Friday, 26 October 2018 18:02:43 UTC-4, Eric Pascual wrote:

Hi,


You mention that adding DRF can actually make you lose some potential benefits 
from caching?


Django does a lot of job WRT caching data at the ORM level and there is a 
"direct path" from the UI and the ORM. I've the feeling that putting a REST API 
in the middle have chances to defeat some of the involved strategies.


I guess DRF can be added to the project at any time


Yes of course, but the views of the UI layer will have to be reworked. When 
dealing directly with the ORM, they use query sets. When the REST API is added, 
you'll have to deal with serializers instead. The migration will represent some 
work.


So if you think that there are 80% of chances the application will evolve to a 
REST API based architecture in a not too distant future, my advice would be 
introduced it from the begining.


But once again, this is a matter of appreciation.


Best


Eric PASCUAL

Centre Scientifique et Technique du Bâtiment
290 route des Lucioles - BP 209
06904 SOPHIA ANTIPOLIS CEDEX
http://www.cstb.fr


From: django...@googlegroups.com  on behalf of 
Tyler Lynch 
Sent: Friday, October 26, 2018 4:18:49 PM
To: Django users
Subject: Re: Should I use Django-Rest-Framework for performance reasons, 
despite not needing an externally-consumable API?

Hi Eric,

Thanks for the response

You mention that adding DRF can actually make you lose some potential benefits 
from caching? Might i ask how that is so? I actually thought it was supposed to 
be the opposite (shows you what I know tho hah)

I guess DRF can be added to the project at any time tho, so there's no need to 
build the project with DRF built-in from beginning. So if I do need it down the 
road, it won't be difficult to add it in.


On Friday, 26 October 2018 04:28:23 UTC-4, Eric Pascual wrote:

Hi,


Using DRF can help when there is a need for decoupling the presentation layer 
from the logic one, for instance if the logic is planned to be used in other 
scenarios that the interactive Web app.


One can argue that structuring the logic as a Python package can do it, but 
this will not work if the deployment involves splitting front-end and logic 
back-end in distinct nodes (f.i. in a Docker multi-container based deployment).


Introducing DRF adds for sure a level of complexity and you'll loose some 
potential caching benefits, but it lets the path opened if ever the above 
mentioned evolution of the application appears in the future. You will not have 
to refactor anything then.


The bottom line is that there is no absolute answer to the question. It depends 
on what can be the plans for the application evolutions in the future.


Regards


Eric


From: django...@googlegroups.com  on behalf of 
Andréas Kühne 
Sent: Friday, October 26, 2018 9:29:40 AM
To: django...@googlegroups.com
Subject: Re: Should I use Django-Rest-Framework for performance reasons, 
despite not needing an externally-consumable API?

Hi,

I really don't get why you would want to do that? If you are doing only a 
"standard" website - you don't want or NEED the extra complexity of running 
DRF. It's not that DRF is hard to setup - but for example if you want to 
present a list of items - in "standard" django, you create the list and add it 

Re: Django to serve JSON: overkill?

[PASCUAL Eric]

Hi,


If the JSON is related to a data model, and if this model is elaborated and 
subject to evolution in the furure, Django can help a lot. Add Django 
RESTFramework to the combo to take care of the REST stuff.


If not, I'd suggest Falcon (https://falconframework.org/), which is a light and 
very efficient framework made for developing REST based services. I've used it 
quite a lot for writing micro-services of a complex platform. Services working 
with data models are developed on top of Django. The other ones are Falcon 
based.

Falcon - Bare-metal web API framework for Python
falconframework.org
Extended Test. Falcon was also benchmarked under CPython 3.6 with a more 
realistic scenario, in which the routing table had multiple entries, the query 
string contained percent-encoded characters, and several complex response 
headers were set in the response.

Hope this helps


Eric


From: django-users@googlegroups.com  on behalf 
of Charley Paulus 
Sent: Saturday, October 27, 2018 3:13:33 PM
To: Django users
Subject: Django to serve JSON: overkill?

Hi,

Is it overkill to use Django just to dispatch url requests and to reply with 
JSON (i.e. not using at all the HTML template engine)?

Thanks.

Best regards,
Charley

--
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/fac5482d-3d6d-4970-8700-61a710026ba5%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/VI1P193MB04326D9BB6EB175F38C29FD58CF20%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM.
For more options, visit https://groups.google.com/d/optout.