(Newbie) Stuck with annotate() docs
Folks, I'm having exceptional trouble understanding annotate(), aggregate(), and their various combinations. I'm currently stuck here: https://docs.djangoproject.com/en/1.9/topics/db/aggregation/#combining-multiple-aggregations The example here uses Book.objects.first().chapters.count(), but there's no chapters model or field at the start of the tutorial. It's frustrating, to say the least. Even if I set up a separate application to test this myself, what do I make of "chapters"? Is it another model with many-to-many relation with Book? When I ran an example with the following models: class Author(models.Model): name = models.CharField(max_length=100) age = models.IntegerField() class Book(models.Model): name = models.CharField(max_length=300) chapters = models.IntegerField() authors = models.ManyToManyField(Author) I got: >>> Book.objects.first().chapters.count() Traceback (most recent call last): File "", line 1, in AttributeError: 'int' object has no attribute 'count' >>> So basically, I feel like I'm screwed. Please help. -- 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/ea169a1e-d55a-457c-b0bd-19d6d96626d7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: (Newbie) Stuck with annotate() docs
I'm not sure how Book.objects.first().chapters is different from Book.objects.first().chapters.count(), but the point is that "chapters" is not defined in the models at the top of that page! The snippet makes sense if I treat Book.chapters as another ManyToManyField (like authors), but it's really weird to see that error in the docs. So, does that mean I can report it? If yes, to who? On Wednesday, April 27, 2016 at 4:36:40 AM UTC+5:30, Tim Graham wrote: > > Looks like a typo. Does the rest of the example make sense and work if > that line is changed to "Book.objects.first().chapters"? > > On Tuesday, April 26, 2016 at 12:50:31 PM UTC-4, Ankush Thakur wrote: >> >> Folks, I'm having exceptional trouble understanding annotate(), >> aggregate(), and their various combinations. I'm currently stuck here: >> https://docs.djangoproject.com/en/1.9/topics/db/aggregation/#combining-multiple-aggregations >> >> The example here uses Book.objects.first().chapters.count(), but there's >> no chapters model or field at the start of the tutorial. It's frustrating, >> to say the least. Even if I set up a separate application to test this >> myself, what do I make of "chapters"? Is it another model with many-to-many >> relation with Book? When I ran an example with the following models: >> >> class Author(models.Model): >> name = models.CharField(max_length=100) >> age = models.IntegerField() >> >> class Book(models.Model): >> name = models.CharField(max_length=300) >> chapters = models.IntegerField() >> authors = models.ManyToManyField(Author) >> >> I got: >> >> >>> Book.objects.first().chapters.count() >> Traceback (most recent call last): >> File "", line 1, in >> AttributeError: 'int' object has no attribute 'count' >> >>> >> >> So basically, I feel like I'm screwed. Please help. >> > -- 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/9d9fee0c-c4d0-4f2d-9575-f6f4e4bfab3a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: (Newbie) Stuck with annotate() docs
Yup! Makes sense now. I hope it saves someone some trouble someday. :-) Thanks a lot, Tim! Best, Ankush On Thursday, April 28, 2016 at 12:21:35 AM UTC+5:30, Tim Graham wrote: > > Please give this a try: https://github.com/django/django/pull/6524 > > On Wednesday, April 27, 2016 at 10:45:03 AM UTC-4, Ankush Thakur wrote: >> >> I'm not sure how Book.objects.first().chapters is different >> from Book.objects.first().chapters.count(), but the point is that >> "chapters" is not defined in the models at the top of that page! The >> snippet makes sense if I treat Book.chapters as another ManyToManyField >> (like authors), but it's really weird to see that error in the docs. So, >> does that mean I can report it? If yes, to who? >> >> On Wednesday, April 27, 2016 at 4:36:40 AM UTC+5:30, Tim Graham wrote: >>> >>> Looks like a typo. Does the rest of the example make sense and work if >>> that line is changed to "Book.objects.first().chapters"? >>> >>> On Tuesday, April 26, 2016 at 12:50:31 PM UTC-4, Ankush Thakur wrote: >>>> >>>> Folks, I'm having exceptional trouble understanding annotate(), >>>> aggregate(), and their various combinations. I'm currently stuck here: >>>> https://docs.djangoproject.com/en/1.9/topics/db/aggregation/#combining-multiple-aggregations >>>> >>>> The example here uses Book.objects.first().chapters.count(), but >>>> there's no chapters model or field at the start of the tutorial. It's >>>> frustrating, to say the least. Even if I set up a separate application to >>>> test this myself, what do I make of "chapters"? Is it another model with >>>> many-to-many relation with Book? When I ran an example with the following >>>> models: >>>> >>>> class Author(models.Model): >>>> name = models.CharField(max_length=100) >>>> age = models.IntegerField() >>>> >>>> class Book(models.Model): >>>> name = models.CharField(max_length=300) >>>> chapters = models.IntegerField() >>>> authors = models.ManyToManyField(Author) >>>> >>>> I got: >>>> >>>> >>> Book.objects.first().chapters.count() >>>> Traceback (most recent call last): >>>> File "", line 1, in >>>> AttributeError: 'int' object has no attribute 'count' >>>> >>> >>>> >>>> So basically, I feel like I'm screwed. Please help. >>>> >>> -- 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/20a60d70-ef3b-4036-9e5d-dbe228a250ef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
1.8 or 1.9?
I want to take a Udemy course on Django because it shows how to make an e-commerce website. The only catch - it follows Django 1.8. So my question is: Will I be "wasting" my time learning a possibly outdated (or unrecommended) version of Django? I have a feeling the changes aren't going to be that significant, but later on when I recreate the project myself in 1.9, I wouldn't want to tear out my hair solving weird error messages. Any wise words? Regards, Ankush Thakur -- 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/CALX%3DrKKkt-%2BcGGM%3DgZFhCYwz6XZMkLoLy%3DUa6Mr6vrzz5B8A8w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: 1.8 or 1.9?
Thank you, Florian! :-) Indeed, stability and job market are what's on my mind. It's comforting to know what I can stick to LTS versions and be assured of (almost 100%) stability. Just another minor concern: What if, say, the other minor upgrade rolls out a really cool feature that takes out a lot of pain than when performing certain tasks in 1.8? I hope it won't feel like I'm stuck with maintaining VB code while the world has moved on? :P Best, Ankush On Thursday, May 12, 2016 at 10:43:07 PM UTC+5:30, Florian Schweikert wrote: > > On 12/05/16 18:36, Sean McKinley wrote: > > I haven't taken the course, but the differences between basic Django 1.8 > > and 1.9 are not all that significant and you can find out if you are > > being taught something odd by reviewing 1.9 release notes. Big caveat, > > syncdb is gone in 1.9 so you have to learn migrations if the Udemy > > course is using syncdb. > > syncdb was deprecated in 1.7, with release of the django migrations. > So basically the only difference may be using another command for the > same thing. > If there are no deprecation warnings using the app with 1.8 it should be > no problem to upgrade to 1.9. > The main difference between 1.8 and 1.9 in my opinion is support. > 1.8 is LTS and will be supported longer than 1.9, we still build all new > applications for our customers with 1.8 at work because of the longer > support. > Most of the features of 1.9 are possible to install as python package, > like the new admin theme and PermissionMixins/django-braces > > Upgrading a minor version is mostly easy and a good thing to learn ;) > > -- > Florian > -- 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/4bde2ebd-0e0d-43c0-8930-70bf492c43db%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: 1.8 or 1.9?
I've done the official tutorial and the Django Girls tutorial (I like the latter better ^.^) but now want to learn to build something nontrivial. I saw a thread on Reddit that talked about frustrations arising from minor inconsistencies between libraries and non-LTS releases. What would be your thoughts on that? On Friday, May 13, 2016 at 5:40:34 AM UTC+5:30, dk wrote: > > will be better to hit your head vs the wall now using 1.9, > than later in a real project,plus there is not much difference, they > added a couple of things, but mostly is the same, I would do the Django > tutorial of Django website before, step by step. > > On Thursday, May 12, 2016 at 8:55:15 AM UTC-7, Ankush Thakur wrote: > >> I want to take a Udemy course on Django because it shows how to make an >> e-commerce website. The only catch - it follows Django 1.8. So my question >> is: Will I be "wasting" my time learning a possibly outdated (or >> unrecommended) version of Django? I have a feeling the changes aren't going >> to be that significant, but later on when I recreate the project myself in >> 1.9, I wouldn't want to tear out my hair solving weird error messages. >> >> Any wise words? >> >> Regards, >> Ankush Thakur >> > -- 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/d68f9f58-d5d5-4776-9a38-12a4916fd8bf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
A question on save_m2m()
So the following section from the docs has me a little confused: = Another side effect of using commit=False is seen when your model has a many-to-many relation with another model. If your model has a many-to-many relation and you specify commit=False when you save a form, Django cannot immediately save the form data for the many-to-many relation. This is because it isn’t possible to save many-to-many data for an instance until the instance exists in the database. To work around this problem, every time you save a form using commit=False, Django adds a save_m2m() method to your ModelForm subclass. After you’ve manually saved the instance produced by the form, you can invoke save_m2m() to save the many-to-many form data. For example: # Create a form instance with POST data. >>> f = AuthorForm(request.POST) # Create, but don't save the new author instance. >>> new_author = f.save(commit=False) # Modify the author in some way. >>> new_author.some_field = 'some_value' # Save the new instance. >>> new_author.save() # Now, save the many-to-many data for the form. >>> f.save_m2m() == I can understand why Django doesn't save Many-to-Many data when commit is set to False, but why do we need to manually call save_m2m() after doing save() manually? Why doesn't Django update the associated Many-to-Many data automatically in this case? Regards, Ankush Thakur -- 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/CALX%3DrK%2B1wQNHk5EJ_WqvEWdk%2BJ0BGnBen%3DmN9FLoc6OB%2Bh2Dqg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Django get_prep_value giving headache
So I'm trying to re-do my personal blog in Django, and have messed up the models and all a bit. Here's the model file: http://pastebin.com/sFhnLkWS Basically what happened was that at the start I had only the Post model. Then I added the Category model and put in a ForeignKey field in Post. Then while migrating, Django complained something about adding a field to an existing model and gave me two options (1 and 2). I chose to enter a default value there, and ended up typing 'Programming', thinking that would be a nice default value for my category. Of course I was an idiot and didn't realize I was supposed to enter a value for the primary key. Now, however, when I run my tests, I get a long traceback which ends in: ValueError: invalid literal for int() with base 10: 'Programming' How can I undo this sin? Regards, Ankush Thakur -- 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/CALX%3DrKLVdP1qOn1RPkoViNT%2Ba2YJdr-TptkO-KJ19Lstuu0Rgw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: A question on save_m2m()
Ah! Stupid, stupid me. Thanks a lot for clarifying! :-) Best, Ankush On Wednesday, May 18, 2016 at 12:15:57 PM UTC+5:30, James Schneider wrote: > > > > On Sat, May 14, 2016 at 2:42 AM, Ankush Thakur > wrote: > >> So the following section from the docs has me a little confused: >> >> = >> Another side effect of using commit=False is seen when your model has a >> many-to-many relation with another model. If your model has a many-to-many >> relation and you specify commit=False when you save a form, Django cannot >> immediately save the form data for the many-to-many relation. This is >> because it isn’t possible to save many-to-many data for an instance until >> the instance exists in the database. >> >> To work around this problem, every time you save a form using >> commit=False, Django adds a save_m2m() method to your ModelForm subclass. >> After you’ve manually saved the instance produced by the form, you can >> invoke save_m2m() to save the many-to-many form data. For example: >> >> # Create a form instance with POST data. >> >>> f = AuthorForm(request.POST) >> >> # Create, but don't save the new author instance. >> >>> new_author = f.save(commit=False) >> >> # Modify the author in some way. >> >>> new_author.some_field = 'some_value' >> >> # Save the new instance. >> >>> new_author.save() >> >> # Now, save the many-to-many data for the form. >> >>> f.save_m2m() >> == >> >> I can understand why Django doesn't save Many-to-Many data when commit is >> set to False, but why do we need to manually call save_m2m() after doing >> save() manually? Why doesn't Django update the associated Many-to-Many data >> automatically in this case? >> >> > Look a bit closer at the process you listed from the docs: > > The initial f.save(commit=False) is run on the bound ModelForm object, and > returns an unsaved Author object (new_author), which means that the M2M > relations are not saved either (since you can't save a M2M without a fully > saved/initialized object already in the DB). > > You are then running save() on new_author, not on f, which means you are > saving the primary model instance returned by the form, not saving the form > itself. > > The last step is the f.save_m2m() call, which tells the form (not > new_author) to grab the related objects and tie them to your new_author > object, and completes saving all pieces of the form. > > HTH, > > -James > -- 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/57d075d8-27d2-4917-a65c-a9ccc45bbd6d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Django websites for study and improvement
Are there any large-ish (I mean, beyond blogs, polls, etc.) websites (web apps?) out there that are open source and can help me learn in the real world? I have covered the basics, even converted my own blog into Django, but I feel I don't know anything about how Django is used out in the wild. I can choose to study the django.contrib apps, but my focus is not on diving into Django's internals right now. Any recommendations? Regards, Ankush Thakur -- 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/CALX%3DrKLxPaV6XeJJCDphaXUpHc7VdyjMepTUE0bH%2BGZaSU-4pg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Why are models must for permissions?
Why are all permissions linked to a model? I'm just learning the basics of permissions and wanted to set up a quick example where I wanted to have a single user who belongs to a group that has permission to access restricted content, let's say. So far I have created a group and added the user to that group but now I am stuck -- which model should I associate the permission with? Should it be the User model here? Why not some other model? Why a model at all? This example in the docs also has me confused: https://docs.djangoproject.com/en/1.9/topics/auth/default/#groups It looks like we are creating a generic permission here (generic in the sense that Django doesn't know what to do with it right out of the box). Why, then, must it be tied to the BlogPost model? I guess my broader concern is that a permission like 'access_restricted_content' is not linked to any one model. Maybe there's a way to create permissions without a model and I've missed it? I think I'm going nuts . . . ~~Ankush -- 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/be02e8a3-ca72-47b6-b66d-152894c52e30%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Django websites for study and improvement
Superb recommendation, Tim! Thanks once again! :D :D ~~Ankush On Wednesday, June 1, 2016 at 8:18:46 PM UTC+5:30, Tim Graham wrote: > > You might enjoy looking at djangoproject.com itself: > https://github.com/django/djangoproject.com/ > > On Tuesday, May 31, 2016 at 1:56:39 PM UTC-4, Ankush Thakur wrote: >> >> Are there any large-ish (I mean, beyond blogs, polls, etc.) websites (web >> apps?) out there that are open source and can help me learn in the real >> world? I have covered the basics, even converted my own blog into Django, >> but I feel I don't know anything about how Django is used out in the wild. >> >> I can choose to study the django.contrib apps, but my focus is not on >> diving into Django's internals right now. >> >> Any recommendations? >> >> Regards, >> Ankush Thakur >> > -- 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/4dc15205-c6b6-4849-8917-390bae65222f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Django websites for study and improvement
Wow, that's quite a lot! Thanks, Akhil! Can I write to you with (silly) questions I might have about these? :P ~~Ankush On Tuesday, May 31, 2016 at 11:39:53 PM UTC+5:30, Akhil Lawrence wrote: > > You can get many django based applications from github. > > https://github.com/taigaio/taiga-back > https://github.com/mayan-edms/mayan-edms/ > https://github.com/stephenmcd/cartridge > > You can also refer > > https://github.com/rosarior/awesome-django > https://github.com/search?q=django > > > Even though you are not interested in django internals.. this might be > helpful > > http://ccbv.co.uk/ > > > > On Tuesday, 31 May 2016 23:26:39 UTC+5:30, Ankush Thakur wrote: >> >> Are there any large-ish (I mean, beyond blogs, polls, etc.) websites (web >> apps?) out there that are open source and can help me learn in the real >> world? I have covered the basics, even converted my own blog into Django, >> but I feel I don't know anything about how Django is used out in the wild. >> >> I can choose to study the django.contrib apps, but my focus is not on >> diving into Django's internals right now. >> >> Any recommendations? >> >> Regards, >> Ankush Thakur >> > -- 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/ab950713-d30b-4ab6-93f2-b7b425816e6b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Adding Tinymce to Admin
I wish to add TinyMCE editor to my Django-powered app. My Model is a typical blog model, with a TextField for the actual post contents. Now what I want is, every time I'm editing the contents (or adding a new blog), I should be able to write in a WordPress-style editor. I understand that I'd need to add some third-party app for TinyMCE and then set it as a widget, but my problem is that the admin templates do not reside in my project Git repository. They are in the virtualenv directory, and I'm not sure how I'll be able to integrate them into my project. A little voice at the back of my head tells me that I won't need to alter Admin, but I'm not sure. Because I don't have any forms (I directly edit/create from the Admin), I don't think I can get away with only saying something like 'content = models.TextField(widget='tinymce')'? Regards, Ankush Thakur -- 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/CALX%3DrKLBResPR-n8SCibpckFAN5PwhHWSH5xBgEnmPaGLUvsrw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Quick-render an object in generic CBV
I'm exploring generic class-based views these days, and was wondering about something. When I use DetailView, the object gets passed to the template, where I have to print all of the properties one by one in the desired HTML element. I was wondering if it's possible to quick-render an object the way we do with model forms? I mean, is there some way I can say something like 'object.as_table()'? I thought of using FormView as a substitute for this, but that requires data to be present in POST, and forcibly populating POST seems like a bad idea. Any thoughts? Regards, Ankush Thakur -- 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/CALX%3DrK%2BYJkSS_GVRzE3n7oDRwsU%2B21BR8o_1jMXCFxqynh0n9A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Adding Tinymce to Admin
Ah, yes! I entirely forgot about admin.py, my head swirling with too many concepts to remember. Let me work on that see how it goes. Thanks! :-) ~~Ankush On Thursday, June 9, 2016 at 2:20:04 PM UTC+5:30, ludovic coues wrote: > > I'm pretty sure you can specify a widget to use in admin for each model > and field. > > Part 7 of the tutorial will show you how to alter the admin without > changing the file in the virtualenv. > The documentation on ModelAdmin have an example of what you are trying to > do :) > > +33614874342 > On 8 Jun 2016 6:56 p.m., "Ankush Thakur" > wrote: > >> I wish to add TinyMCE editor to my Django-powered app. My Model is a >> typical blog model, with a TextField for the actual post contents. Now what >> I want is, every time I'm editing the contents (or adding a new blog), I >> should be able to write in a WordPress-style editor. >> >> I understand that I'd need to add some third-party app for TinyMCE and >> then set it as a widget, but my problem is that the admin templates do not >> reside in my project Git repository. They are in the virtualenv directory, >> and I'm not sure how I'll be able to integrate them into my project. >> >> A little voice at the back of my head tells me that I won't need to alter >> Admin, but I'm not sure. Because I don't have any forms (I directly >> edit/create from the Admin), I don't think I can get away with only saying >> something like 'content = models.TextField(widget='tinymce')'? >> >> Regards, >> Ankush Thakur >> >> -- >> 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...@googlegroups.com . >> To post to this group, send email to django...@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/CALX%3DrKLBResPR-n8SCibpckFAN5PwhHWSH5xBgEnmPaGLUvsrw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/django-users/CALX%3DrKLBResPR-n8SCibpckFAN5PwhHWSH5xBgEnmPaGLUvsrw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> 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/d990f370-741c-4c88-9e34-95d9f18aca9c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Adding Tinymce to Admin
Nope. And you know why, coz I'm an idiot! :P Will try this and post here if I run into problems. Thanks a ton! ~~Ankush On Thursday, June 9, 2016 at 5:15:52 PM UTC+5:30, jorr...@gmail.com wrote: > > Have you looked at https://github.com/aljosa/django-tinymce ? > -- 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/4ee8d6d4-c633-4327-80c0-cb7042024e7b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Confused about this aggregation example from the docs
On this page https://docs.djangoproject.com/en/1.9/topics/db/aggregation/
we have the following example of aggregation:
# All the following queries involve traversing the Book<->Publisher
# foreign key relationship backwards.
# Each publisher, each with a count of books as a "num_books" attribute.
>>> from django.db.models import Count
>>> pubs = Publisher.objects.annotate(num_books=Count('book'))
>>> pubs
[, , ...]
>>> pubs[0].num_books
73
The models used in this are as follows:
from django.db import models
class Author(models.Model):
name = models.CharField(max_length=100)
age = models.IntegerField()
class Publisher(models.Model):
name = models.CharField(max_length=300)
num_awards = models.IntegerField()
class Book(models.Model):
name = models.CharField(max_length=300)
pages = models.IntegerField()
price = models.DecimalField(max_digits=10, decimal_places=2)
rating = models.FloatField()
authors = models.ManyToManyField(Author)
publisher = models.ForeignKey(Publisher)
pubdate = models.DateField()
class Store(models.Model):
name = models.CharField(max_length=300)
books = models.ManyToManyField(Book)
registered_users = models.PositiveIntegerField()
My question is: How come something like
"Publisher.objects.annotate(num_books=Count('book'))" work? The name "book"
is not defined as a reverse relationship (I think it should be accessible
by "book_set").
How is this traversal working?
Regards,
Ankush Thakur
--
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/CALX%3DrKJNHcLXfwv%2BYCH0OXLq%2BLgSsWsbp9uex_6r%3DrU9ztV2dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Serving static files
I keep hearing in the docs and in tutorials that frameworks are horrible when it comes to service static files. In production, also, one needs to set up another dedicated server to serve static files. I'm wondering why. What is so special about serving static files that a framework comes to a halt, even though the same framework can happily serve thousands of requests per hour? Regards, Ankush Thakur -- 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/CALX%3DrKLw_nMxZz7xeC0N%3D5Zwn0Q0eZnV_GFGkdwmP-%3DabtPMUQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Serving static files
Thanks but I'm afraid I wasn't able to grasp the point of that article. Could you break it down for me, please? ~~Ankush On Monday, June 27, 2016 at 10:07:43 PM UTC+5:30, ludovic coues wrote: > > It's not that the framework will come to an halt. It's that a server > serving static file directly would be an order of magnitude faster. > > https://unix4lyfe.org/time/hn.html is a nice article on how server > react to heavy load when serving static file. > > 2016-06-27 18:26 GMT+02:00 Ankush Thakur >: > > I keep hearing in the docs and in tutorials that frameworks are horrible > > when it comes to service static files. In production, also, one needs to > set > > up another dedicated server to serve static files. > > > > I'm wondering why. What is so special about serving static files that a > > framework comes to a halt, even though the same framework can happily > serve > > thousands of requests per hour? > > > > Regards, > > Ankush Thakur > > > > -- > > 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...@googlegroups.com . > > To post to this group, send email to django...@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/CALX%3DrKLw_nMxZz7xeC0N%3D5Zwn0Q0eZnV_GFGkdwmP-%3DabtPMUQ%40mail.gmail.com. > > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > Cordialement, Coues Ludovic > +336 148 743 42 > -- 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/4ee672fa-f6d8-4882-8420-ac57032e4904%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Serving static files
Hmmm. One argument I read supporting separate servers is that it would save the main server a few socket connections. But this appears to be too little of a gain. The approach of using a CDN, I think, is much more sensible. Thanks once again, Tim! Regards, Ankush Thakur On Wed, Jun 29, 2016 at 7:33 AM, Tim Graham wrote: > The concerns about needing a separate server are likely overblown. In > particular, Whitenoise is a popular solution for static file serving using > Python. See its FAQ: > http://whitenoise.evans.io/en/stable/#isn-t-serving-static-files-from-python-horribly-inefficient > > On Tuesday, June 28, 2016 at 9:59:26 PM UTC-4, Ankush Thakur wrote: >> >> Thanks but I'm afraid I wasn't able to grasp the point of that article. >> Could you break it down for me, please? >> >> ~~Ankush >> >> On Monday, June 27, 2016 at 10:07:43 PM UTC+5:30, ludovic coues wrote: >>> >>> It's not that the framework will come to an halt. It's that a server >>> serving static file directly would be an order of magnitude faster. >>> >>> https://unix4lyfe.org/time/hn.html is a nice article on how server >>> react to heavy load when serving static file. >>> >>> 2016-06-27 18:26 GMT+02:00 Ankush Thakur : >>> > I keep hearing in the docs and in tutorials that frameworks are >>> horrible >>> > when it comes to service static files. In production, also, one needs >>> to set >>> > up another dedicated server to serve static files. >>> > >>> > I'm wondering why. What is so special about serving static files that >>> a >>> > framework comes to a halt, even though the same framework can happily >>> serve >>> > thousands of requests per hour? >>> > >>> > Regards, >>> > Ankush Thakur >>> > >>> > -- >>> > 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...@googlegroups.com. >>> > To post to this group, send email to django...@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/CALX%3DrKLw_nMxZz7xeC0N%3D5Zwn0Q0eZnV_GFGkdwmP-%3DabtPMUQ%40mail.gmail.com. >>> >>> > For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> -- >>> >>> Cordialement, Coues Ludovic >>> +336 148 743 42 >>> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "Django users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-users/U1Y52ad4lDM/unsubscribe. > To unsubscribe from this group and all its topics, 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/c2f1699e-9bfc-43f4-a858-a54a256cec1d%40googlegroups.com > <https://groups.google.com/d/msgid/django-users/c2f1699e-9bfc-43f4-a858-a54a256cec1d%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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/CALX%3DrKKR-40%2B%3DjssfSk6HEaTk3ibkKQqENDA6gQ2Acjzm2q3bg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Question about model attributes
I recently was introduced to the concept of descriptors in Python, and it looks like fields like CharField() are descriptors. However, I find the concept of descriptors quite enigmatic, and am trying to piece together the puzzle bu asking related questions. For now my question is: What do we gain by having these attributes on the class rather than on the instance? I mean, why can't the fields we are using in a model be defined in __init__()? I know it's common practice to instantiate descriptors on a class-level, but I don't know why. I'm confused because one link I found ( http://stackoverflow.com/questions/2714573/instance-variables-vs-class-variables-in-python) recommends putting attributes in instances than class. I guess what I am asking is more of a Python question than a Django one, but because Django is actually using this language feature to do something real-world, I thought of tossing the question here. Regards, Ankush Thakur -- 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/CALX%3DrK%2BgFvXqpew4vk9N6J0SqugWOUM3sjz%3DGHo8yD1b%2BQQG7A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Confused about this aggregation example from the docs
Ah, that totally skipped my mind.
Thanks yet once again, Tim! :-)
Best,
Ankush
On Wednesday, June 29, 2016 at 7:18:31 AM UTC+5:30, Tim Graham wrote:
>
> 'book' (the model name) is the default value of ForeignKey.related_name
> for the publisher field on Book.
>
> class Book(models.Model):
> publisher = models.ForeignKey(Publisher, on_delete=models.CASCADE)
>
>
> https://docs.djangoproject.com/en/stable/ref/models/fields/#django.db.models.ForeignKey.related_name
>
> On Saturday, June 25, 2016 at 10:11:44 AM UTC-4, Ankush Thakur wrote:
>>
>> On this page https://docs.djangoproject.com/en/1.9/topics/db/aggregation/
>> we have the following example of aggregation:
>>
>> # All the following queries involve traversing the Book<->Publisher
>> # foreign key relationship backwards.
>>
>> # Each publisher, each with a count of books as a "num_books" attribute.
>> >>> from django.db.models import Count
>> >>> pubs = Publisher.objects.annotate(num_books=Count('book'))
>> >>> pubs
>> [, , ...]
>> >>> pubs[0].num_books
>> 73
>>
>> The models used in this are as follows:
>>
>> from django.db import models
>>
>> class Author(models.Model):
>> name = models.CharField(max_length=100)
>> age = models.IntegerField()
>>
>> class Publisher(models.Model):
>> name = models.CharField(max_length=300)
>> num_awards = models.IntegerField()
>>
>> class Book(models.Model):
>> name = models.CharField(max_length=300)
>> pages = models.IntegerField()
>> price = models.DecimalField(max_digits=10, decimal_places=2)
>> rating = models.FloatField()
>> authors = models.ManyToManyField(Author)
>> publisher = models.ForeignKey(Publisher)
>> pubdate = models.DateField()
>>
>> class Store(models.Model):
>> name = models.CharField(max_length=300)
>> books = models.ManyToManyField(Book)
>> registered_users = models.PositiveIntegerField()
>>
>> My question is: How come something like
>> "Publisher.objects.annotate(num_books=Count('book'))" work? The name "book"
>> is not defined as a reverse relationship (I think it should be accessible
>> by "book_set").
>>
>> How is this traversal working?
>>
>>
>> Regards,
>> Ankush Thakur
>>
>
--
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/cd9a9b34-6952-41b6-98db-5f65f6e3cc62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Unable to set up celery in supervisord
I'm trying to set up celery as a supervisord job (for my Django project)
and getting an error. Most likely it's because of wrong import paths (or
some other environment setting), but I have no idea what. Please help!
Here's my directory structure ('>' means down one level):
/home/ankush/jremind
>env
>jremind
>>celerybeat.pid
>>celerybeat-schedule
>>jremind
>>manage.py
>>remind
>>requirements.txt
>logs
The supervisord conf file is:
command=/home/ankush/jremind/env/bin/celery --app=remind.celery:app worker
--loglevel=INFO
environment=PYTHONPATH=/home/ankush/jremind/jremind
directory=/home/ankush/jremind/jremind
stdout_logfile=/home/ankush/jremind/logs/celeryd.log
stderr_logfile=/home/ankush/jremind/logs/celeryd.log
autostart=true
autorestart=true
startsecs=10
stopwaitsecs=600
Now, when I try to start the process, it exists too quickly, and I'm left
with the following in the logs:
. . .
self._conf = force_mapping(obj)
File
"/home/ankush/jremind/env/lib/python3.4/site-packages/celery/datastructures.py",
line 50, in force_mapping
if isinstance(m, (LazyObject, LazySettings)):
File
"/home/ankush/jremind/env/lib/python3.4/site-packages/django/utils/functional.py",
line 204, in inner
self._setup()
File
"/home/ankush/jremind/env/lib/python3.4/site-packages/django/conf/__init__.py",
line 43, in _setup
self._wrapped = Settings(settings_module)
File
"/home/ankush/jremind/env/lib/python3.4/site-packages/django/conf/__init__.py",
line 120, in __init__
raise ImproperlyConfigured("The SECRET_KEY setting must not be empty.")
django.core.exceptions.ImproperlyConfigured: The SECRET_KEY setting must
not be empty.
I'm not sure why I'm getting this error, because the secret key is most
definitely there and the app runs fine. What am I doing wrong?
Best,
Ankush
--
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/CALX%3DrKLVqMePZnsZ5SGRb4bqoyahAQOBbheWshH%2B5PXGdnQw%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Unable to set up celery in supervisord
Well, setting up the line this way gives me the following error: Starting supervisor: Error: Format string 'PYTHONPATH=/home/ankush/jremind/jremind,JREMIND_SECRET_KEY="SDFDSF@$%#$%$#TWFDFGFG%^$%ewrw$#%TFRETERTERT$^",JREMIND_DATABASE="jremind",JREMIND_USERNAME="root",JREMIND_PASSWORD="root"' for 'environment' is badly formatted What do you think is badly formatted here? Best, Ankush On Thursday, July 21, 2016 at 11:51:19 PM UTC+5:30, george wrote: > > If you are getting variables from the environment, supervisor that special > environment directive. The variables need to specified in the supervisor > conf file, such as: > > command=/home/ankush/jremind/env/bin/celery --app=remind.celery:app > worker --loglevel=INFO > environment=PYTHONPATH=/home/ankush/jremind/jremind, > *SECRET_KEY="foo",VARIABLE_A="a"* > directory=/home/ankush/jremind/jremind > stdout_logfile=/home/ankush/jremind/logs/celeryd.log > stderr_logfile=/home/ankush/jremind/logs/celeryd.log > autostart=true > autorestart=true > startsecs=10 > stopwaitsecs=600 > > Supervisor won't be able to read them otherwise. There are other > alternatives, for example, if you are using a crafted command, using bash: > > command=/home/foo/command.sh > environment=PYTHONPATH=/home/ankush/jremind/jremind > directory=/home/ankush/jremind/jremind > stdout_logfile=/home/ankush/jremind/logs/celeryd.log > stderr_logfile=/home/ankush/jremind/logs/celeryd.log > autostart=true > autorestart=true > startsecs=10 > stopwaitsecs=600 > > > command.sh > > !#/bin/bash > > export SECRET_KEY="foo" > export VARIABLE_A="a" > > echo $SECRET_KEY > echo $VARIABLE_A > > > -- > George R. C. Silva > Sigma Geosistemas LTDA > > http://www.sigmageosistemas.com.br/ > -- 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/f9639cef-0a04-4982-92b4-9c8a9c5a1158%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Unable to set up celery in supervisord
Wooohooo! That did it. Many thanks! :-) :-) :-) Umm, but, say, isn't kind of clunky, that I have to copy all the variables over to the supervisor config? Isn't there a neater way to do it? Regards, Ankush Thakur On Fri, Jul 22, 2016 at 10:21 PM, George Silva wrote: > The secret key contains % chars. Chance them to something else or escape > them. > > Em 22/07/2016 13:49, "Ankush Thakur" escreveu: > >> Well, setting up the line this way gives me the following error: >> >> Starting supervisor: Error: Format string >> 'PYTHONPATH=/home/ankush/jremind/jremind,JREMIND_SECRET_KEY="SDFDSF@$%#$%$#TWFDFGFG%^$%ewrw$#%TFRETERTERT$^",JREMIND_DATABASE="jremind",JREMIND_USERNAME="root",JREMIND_PASSWORD="root"' >> for 'environment' is badly formatted >> >> What do you think is badly formatted here? >> >> Best, >> Ankush >> >> On Thursday, July 21, 2016 at 11:51:19 PM UTC+5:30, george wrote: >>> >>> If you are getting variables from the environment, supervisor that >>> special environment directive. The variables need to specified in the >>> supervisor conf file, such as: >>> >>> command=/home/ankush/jremind/env/bin/celery --app=remind.celery:app >>> worker --loglevel=INFO >>> environment=PYTHONPATH=/home/ankush/jremind/jremind, >>> *SECRET_KEY="foo",VARIABLE_A="a"* >>> directory=/home/ankush/jremind/jremind >>> stdout_logfile=/home/ankush/jremind/logs/celeryd.log >>> stderr_logfile=/home/ankush/jremind/logs/celeryd.log >>> autostart=true >>> autorestart=true >>> startsecs=10 >>> stopwaitsecs=600 >>> >>> Supervisor won't be able to read them otherwise. There are other >>> alternatives, for example, if you are using a crafted command, using bash: >>> >>> command=/home/foo/command.sh >>> environment=PYTHONPATH=/home/ankush/jremind/jremind >>> directory=/home/ankush/jremind/jremind >>> stdout_logfile=/home/ankush/jremind/logs/celeryd.log >>> stderr_logfile=/home/ankush/jremind/logs/celeryd.log >>> autostart=true >>> autorestart=true >>> startsecs=10 >>> stopwaitsecs=600 >>> >>> >>> command.sh >>> >>> !#/bin/bash >>> >>> export SECRET_KEY="foo" >>> export VARIABLE_A="a" >>> >>> echo $SECRET_KEY >>> echo $VARIABLE_A >>> >>> >>> -- >>> George R. C. Silva >>> Sigma Geosistemas LTDA >>> >>> http://www.sigmageosistemas.com.br/ >>> >> -- >> 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/f9639cef-0a04-4982-92b4-9c8a9c5a1158%40googlegroups.com >> <https://groups.google.com/d/msgid/django-users/f9639cef-0a04-4982-92b4-9c8a9c5a1158%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-users/0yxoRdSyctA/unsubscribe. > To unsubscribe from this group and all its topics, 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/CAGyPVTvOfBvbh_Cpz3ZgRb%3DcfQ3K8FuoS5Xi57FjTdO9aCyQ4g%40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CAGyPVTvOfBvbh_Cpz3ZgRb%3DcfQ3K8FuoS5Xi57FjTdO9aCyQ4g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > 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/CALX%3DrKLWr%3Dc2X_DEo44na6d7GraVve-6qdAWiP2RrdKOC_idJg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Unable to set up celery in supervisord
Unfortunately the docs are anything but beginner-friendly on Celery + Supervisor: http://docs.celeryproject.org/en/latest/tutorials/daemonizing.html#supervisord If you follow the link, you land on a GitHub page with three files and no explanations. :( Besides, if you see https://github.com/celery/celery/blob/3.1/extra/supervisord/celeryd.conf, there's no mention of environment variables. Regards, Ankush Thakur On Fri, Jul 22, 2016 at 10:34 PM, George Silva wrote: > Check the docs. There's plenty of information regarding this. > > It's probably a bad formatted character, misplaced comma or whatever. > > On Fri, Jul 22, 2016 at 1:49 PM, Ankush Thakur > wrote: > >> Well, setting up the line this way gives me the following error: >> >> Starting supervisor: Error: Format string >> 'PYTHONPATH=/home/ankush/jremind/jremind,JREMIND_SECRET_KEY="SDFDSF@$%#$%$#TWFDFGFG%^$%ewrw$#%TFRETERTERT$^",JREMIND_DATABASE="jremind",JREMIND_USERNAME="root",JREMIND_PASSWORD="root"' >> for 'environment' is badly formatted >> >> What do you think is badly formatted here? >> >> Best, >> Ankush >> >> >> On Thursday, July 21, 2016 at 11:51:19 PM UTC+5:30, george wrote: >>> >>> If you are getting variables from the environment, supervisor that >>> special environment directive. The variables need to specified in the >>> supervisor conf file, such as: >>> >>> command=/home/ankush/jremind/env/bin/celery --app=remind.celery:app >>> worker --loglevel=INFO >>> environment=PYTHONPATH=/home/ankush/jremind/jremind, >>> *SECRET_KEY="foo",VARIABLE_A="a"* >>> directory=/home/ankush/jremind/jremind >>> stdout_logfile=/home/ankush/jremind/logs/celeryd.log >>> stderr_logfile=/home/ankush/jremind/logs/celeryd.log >>> autostart=true >>> autorestart=true >>> startsecs=10 >>> stopwaitsecs=600 >>> >>> Supervisor won't be able to read them otherwise. There are other >>> alternatives, for example, if you are using a crafted command, using bash: >>> >>> command=/home/foo/command.sh >>> environment=PYTHONPATH=/home/ankush/jremind/jremind >>> directory=/home/ankush/jremind/jremind >>> stdout_logfile=/home/ankush/jremind/logs/celeryd.log >>> stderr_logfile=/home/ankush/jremind/logs/celeryd.log >>> autostart=true >>> autorestart=true >>> startsecs=10 >>> stopwaitsecs=600 >>> >>> >>> command.sh >>> >>> !#/bin/bash >>> >>> export SECRET_KEY="foo" >>> export VARIABLE_A="a" >>> >>> echo $SECRET_KEY >>> echo $VARIABLE_A >>> >>> >>> -- >>> George R. C. Silva >>> Sigma Geosistemas LTDA >>> >>> http://www.sigmageosistemas.com.br/ >>> >> -- >> 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/f9639cef-0a04-4982-92b4-9c8a9c5a1158%40googlegroups.com >> <https://groups.google.com/d/msgid/django-users/f9639cef-0a04-4982-92b4-9c8a9c5a1158%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > George R. C. Silva > Sigma Geosistemas LTDA > > http://www.sigmageosistemas.com.br/ > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-users/0yxoRdSyctA/unsubscribe. > To unsubscribe from this group and all its topics, 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/CAGyPVTv7X_9Waim0BU7uknipwPAujp5ik7AHSCBmqksRNKaszg%40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CAGyPVTv7X_9Waim0BU7uknipwPAujp5ik7AHSCBmqksRNKaszg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > 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/CALX%3DrK%2BtutoBh3pDMLaH7Xm8MVDf%3DxXgArY7ESWrvniUgsL66w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Unable to set up celery in supervisord
Yes, I guess that's good enough. Thanks for helping out! :-) Regards, Ankush Thakur On Fri, Jul 22, 2016 at 10:54 PM, George Silva wrote: > I'm familiar with the two ways I've explained to you. I'm not sure if > there are others. > > Actually, it's a single place where you have to define the variables (the > supervisor conf) so I don't think it's that bad. > > > > On Fri, Jul 22, 2016 at 2:18 PM, Ankush Thakur > wrote: > >> Unfortunately the docs are anything but beginner-friendly on Celery + >> Supervisor: >> http://docs.celeryproject.org/en/latest/tutorials/daemonizing.html#supervisord >> If you follow the link, you land on a GitHub page with three files and no >> explanations. :( >> >> Besides, if you see >> https://github.com/celery/celery/blob/3.1/extra/supervisord/celeryd.conf, >> there's no mention of environment variables. >> >> >> Regards, >> Ankush Thakur >> >> On Fri, Jul 22, 2016 at 10:34 PM, George Silva >> wrote: >> >>> Check the docs. There's plenty of information regarding this. >>> >>> It's probably a bad formatted character, misplaced comma or whatever. >>> >>> On Fri, Jul 22, 2016 at 1:49 PM, Ankush Thakur < >>> ankush.thaku...@gmail.com> wrote: >>> >>>> Well, setting up the line this way gives me the following error: >>>> >>>> Starting supervisor: Error: Format string >>>> 'PYTHONPATH=/home/ankush/jremind/jremind,JREMIND_SECRET_KEY="SDFDSF@$%#$%$#TWFDFGFG%^$%ewrw$#%TFRETERTERT$^",JREMIND_DATABASE="jremind",JREMIND_USERNAME="root",JREMIND_PASSWORD="root"' >>>> for 'environment' is badly formatted >>>> >>>> What do you think is badly formatted here? >>>> >>>> Best, >>>> Ankush >>>> >>>> >>>> On Thursday, July 21, 2016 at 11:51:19 PM UTC+5:30, george wrote: >>>>> >>>>> If you are getting variables from the environment, supervisor that >>>>> special environment directive. The variables need to specified in the >>>>> supervisor conf file, such as: >>>>> >>>>> command=/home/ankush/jremind/env/bin/celery --app=remind.celery:app >>>>> worker --loglevel=INFO >>>>> environment=PYTHONPATH=/home/ankush/jremind/jremind, >>>>> *SECRET_KEY="foo",VARIABLE_A="a"* >>>>> directory=/home/ankush/jremind/jremind >>>>> stdout_logfile=/home/ankush/jremind/logs/celeryd.log >>>>> stderr_logfile=/home/ankush/jremind/logs/celeryd.log >>>>> autostart=true >>>>> autorestart=true >>>>> startsecs=10 >>>>> stopwaitsecs=600 >>>>> >>>>> Supervisor won't be able to read them otherwise. There are other >>>>> alternatives, for example, if you are using a crafted command, using bash: >>>>> >>>>> command=/home/foo/command.sh >>>>> environment=PYTHONPATH=/home/ankush/jremind/jremind >>>>> directory=/home/ankush/jremind/jremind >>>>> stdout_logfile=/home/ankush/jremind/logs/celeryd.log >>>>> stderr_logfile=/home/ankush/jremind/logs/celeryd.log >>>>> autostart=true >>>>> autorestart=true >>>>> startsecs=10 >>>>> stopwaitsecs=600 >>>>> >>>>> >>>>> command.sh >>>>> >>>>> !#/bin/bash >>>>> >>>>> export SECRET_KEY="foo" >>>>> export VARIABLE_A="a" >>>>> >>>>> echo $SECRET_KEY >>>>> echo $VARIABLE_A >>>>> >>>>> >>>>> -- >>>>> George R. C. Silva >>>>> Sigma Geosistemas LTDA >>>>> >>>>> http://www.sigmageosistemas.com.br/ >>>>> >>>> -- >>>> 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 >&g
Flattening model relationships (in APIs)
I'm using DRF for an API. My problem is that I defined my postal address
like this (breaking it up into City, State, Country):
class Country(models.Model):
class Meta:
db_table = 'countries'
name = models.TextField()
code = models.TextField(unique=True)
class State(models.Model):
class Meta:
db_table = 'states'
name = models.TextField()
code = models.TextField(unique=True)
country = models.ForeignKey('Country', on_delete=models.CASCADE)
class City(models.Model):
class Meta:
db_table = 'cities'
name = models.TextField()
code = models.TextField(unique=True)
state = models.ForeignKey('State', on_delete=models.CASCADE)
class Address(models.Model):
class Meta:
db_table = 'addresses'
building_no = models.TextField()
street = models.TextField(null=True)
locality = models.TextField(null=True)
landmark = models.TextField(null=True)
pincode = models.TextField(null=True)
latitude = models.DecimalField(max_digits=9, decimal_places=6,
null=True)
longitude = models.DecimalField(max_digits=9, decimal_places=6,
null=True)
city = models.ForeignKey('City', on_delete=models.CASCADE)
Now, in my system, a venue has an address, and so the serializes are
defined like this:
class VenueSerializer(serializers.ModelSerializer):
address = AddressSerializer()
offerings = OfferingSerializer(many=True)
class Meta:
model = Venue
fields = ['id', 'name', 'price_per_day', 'status', 'offerings',
'address', 'photos']
which leads us to:
class AddressSerializer(serializers.ModelSerializer):
city = CitySerializer()
class Meta:
model = Address
fields = ['id', 'building_no', 'street', 'locality', 'landmark',
'pincode', 'latitude', 'longitude', 'city']
which leads us to:
class CitySerializer(serializers.ModelSerializer):
state = StateSerializer()
class Meta:
model = City
fields = ['id', 'name', 'code', 'state']
which leads us to:
class StateSerializer(serializers.ModelSerializer):
country = CountrySerializer()
class Meta:
model = State
fields = ['id', 'name', 'code', 'country']
which finally leads to:
class CountrySerializer(serializers.ModelSerializer):
class Meta:
model = Country
fields = ['id', 'name', 'code']
and when this gets serialized, the address is given in the following format:
"address": {
"id": 2,
"building_no": "11",
"street": "Another Street",
"locality": "",
"landmark": "Fortis Hospital",
"pincode": "201003",
"latitude": "28.632778",
"longitude": "77.219722",
"city": {
"id": 1,
"name": "Delhi",
"code": "DEL",
"state": {
"id": 1,
"name": "Delhi",
"code": "DEL",
"country": {
"id": 1,
"name": "India",
"code": "IN"
}
}
}
}
So there's a hell lot of nesting from city to state to country. If the
relationship chain was even deeper, there would be even more nesting, which
I feel isn't great for API consumers. What is the best practice here to put
state and country at the same level as the city? I think this will also
complicate the logic while POSTing data, so I'm interested in knowing about
that as well.
I'm sorry if there is too much code, but I couldn't think of a better way
to convey the situation than actually post everything.
Regards,
Ankush Thakur
--
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/CALX%3DrK%2Bgbbro%2BkFYsq%3DFDCSu2kw6KRmsfKRamKLA%2Bisrgj%3DboQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Flattening model relationships (in APIs)
Also, I don't have any need of providing several types of addresses as of now. For now I'm just sticking with outputting everything when the address is requested. ~~ Ankush On Thursday, February 23, 2017 at 9:13:01 PM UTC+5:30, Ankush Thakur wrote: > > Hey Mike, > > Thanks for your thoughts. Perhaps I presented my requirement incorrectly. > I don't at all want to denormalize the database. My point was that because > of the way models are related, I'm ending up with city containing state > containing country. This, I feel, would be a chore for the front-end guys. > So my question is, how can I rearrange these fields to give a flat JSON > output rather than have objects within objects. I hope it makes more sense > now. > > ~~ Ankush > > On Wednesday, February 22, 2017 at 9:59:26 AM UTC+5:30, Mike Dewhirst > wrote: >> >> Ankush >> >> I think you might have to provide more than one method for retrieving an >> address so applications can request particular subsets. Perhaps a >> local-postal address, international-postal address, geo-location, >> what-three-words address and of course the full bucket as required. >> >> I think it is always best to normalize as much as possible in the >> beginning and de-normalize only if performance becomes an issue. >> >> Also ... >> >> >> https://hackernoon.com/10-things-i-learned-making-the-fastest-site-in-the-world-18a0e1cdf4a7#.3l8n34dvk >> >> >> Mike >> > -- 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/e9db76fa-aabc-4546-a80c-af03087e3042%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Flattening model relationships (in APIs)
Hey Mike,
Thanks for your thoughts. Perhaps I presented my requirement incorrectly. I
don't at all want to denormalize the database. My point was that because of
the way models are related, I'm ending up with city containing state
containing country. This, I feel, would be a chore for the front-end guys.
So my question is, how can I rearrange these fields to give a flat JSON
output rather than have objects within objects. I hope it makes more sense
now.
~~ Ankush
On Wednesday, February 22, 2017 at 9:59:26 AM UTC+5:30, Mike Dewhirst wrote:
>
> Ankush
>
> I think you might have to provide more than one method for retrieving an
> address so applications can request particular subsets. Perhaps a
> local-postal address, international-postal address, geo-location,
> what-three-words address and of course the full bucket as required.
>
> I think it is always best to normalize as much as possible in the
> beginning and de-normalize only if performance becomes an issue.
>
> Also ...
>
>
> https://hackernoon.com/10-things-i-learned-making-the-fastest-site-in-the-world-18a0e1cdf4a7#.3l8n34dvk
>
>
> Mike
>
> On 22/02/2017 6:09 AM, Ankush Thakur wrote:
> > I'm using DRF for an API. My problem is that I defined my postal
> > address like this (breaking it up into City, State, Country):
> >
> > class Country(models.Model):
> > class Meta:
> > db_table = 'countries'
> >
> > name = models.TextField()
> > code = models.TextField(unique=True)
> >
> > class State(models.Model):
> > class Meta:
> > db_table = 'states'
> >
> > name = models.TextField()
> > code = models.TextField(unique=True)
> > country = models.ForeignKey('Country', on_delete=models.CASCADE)
> >
> >
> > class City(models.Model):
> > class Meta:
> > db_table = 'cities'
> >
> > name = models.TextField()
> > code = models.TextField(unique=True)
> > state = models.ForeignKey('State', on_delete=models.CASCADE)
> >
> > class Address(models.Model):
> > class Meta:
> > db_table = 'addresses'
> > building_no = models.TextField()
> > street = models.TextField(null=True)
> > locality = models.TextField(null=True)
> > landmark = models.TextField(null=True)
> > pincode = models.TextField(null=True)
> > latitude = models.DecimalField(max_digits=9, decimal_places=6,
> > null=True)
> > longitude = models.DecimalField(max_digits=9, decimal_places=6,
> > null=True)
> > city = models.ForeignKey('City', on_delete=models.CASCADE)
> >
> > Now, in my system, a venue has an address, and so the serializes are
> > defined like this:
> >
> > class VenueSerializer(serializers.ModelSerializer):
> > address = AddressSerializer()
> > offerings = OfferingSerializer(many=True)
> >
> > class Meta:
> > model = Venue
> > fields = ['id', 'name', 'price_per_day', 'status',
> > 'offerings', 'address', 'photos']
> >
> > which leads us to:
> >
> > class AddressSerializer(serializers.ModelSerializer):
> > city = CitySerializer()
> >
> > class Meta:
> > model = Address
> > fields = ['id', 'building_no', 'street', 'locality',
> > 'landmark', 'pincode', 'latitude', 'longitude', 'city']
> >
> > which leads us to:
> >
> > class CitySerializer(serializers.ModelSerializer):
> > state = StateSerializer()
> >
> > class Meta:
> > model = City
> > fields = ['id', 'name', 'code', 'state']
> >
> > which leads us to:
> >
> > class StateSerializer(serializers.ModelSerializer):
> > country = CountrySerializer()
> >
> > class Meta:
> > model = State
> > fields = ['id', 'name', 'code', 'country']
> >
> > which finally leads to:
> >
> > class CountrySerializer(serializers.ModelSerializer):
> > class Meta:
> > model = Country
> > fields = ['id', 'name', 'code']
> >
> > and when this gets serialized, the address is given in the following
> > form
Re: Flattening model relationships (in APIs)
Marcin, that's exactly where I'm stuck! I know endpoints should never be 1:1 serialization of models, but I just don't know how to do that. I mean, I've been able to create endpoints like "/customers/1/payments/" where I use model relationships to generate JSON structures where Customer contains a Payments array field. My Address endpoint seems to be an oddity, as API consumers don't expect the city to contain state and the state to contain country as a JSON structure. How can I add these to the top-level Address entity directly while serialization? That's where I have no answers. Would it be possible for you to point me towards some article that does that? Thanks in advance! Regards, Ankush On Monday, February 27, 2017 at 3:41:49 AM UTC+5:30, marcin@gmail.com wrote: > > > > On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote: >> >> If the relationship chain was even deeper, there would be even more >> nesting, which I feel isn't great for API consumers. What is the best >> practice here to put state and country at the same level as the city? >> > > Just follow REST design. > Forget django models, think about encapsulation. > Think about representation of a resource, not about serializing a model(s). > Make semantic representations, as good as possible. > > You are not forced to do any nested nasty things. This has nothing to do > with REST api. > You may feel that DRF is limiting you. You'll be on a good path, if so. :) > > Good luck! > Marcin > -- 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/70189b7c-69db-4b3a-9c3e-935121b76ea9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Flattening model relationships (in APIs)
Hmmm. That's not an answer I wanted to hear, really, but I like it. I'm
myself finding DRF too restrictive once you are past the effort-saving
magic. Thank you. I might give it up as it's still early days in the
project.
Regards,
Ankush Thakur
On Mon, Feb 27, 2017 at 7:43 PM, wrote:
> I'm not sure you want to read my answer, really... I've finally stopped
> using DRF and wrote own library which is focused on resources, linking and
> representations.
> I think you can do some customization in DRF, probably you ca declare
> custom serializer class, but this is a hard way, IMO.
>
> I like simple things, so with my lib I can just do something like that:
>
> payments = api.resource('/payments/')
> customer = api.resource('/customers/:pk')
>
>
> @payments.representation
> def payment_as_json(payment, ctx):
> return {
> 'customer_address': payment.customer.address,
> 'customer_url': ctx.link_to(customer, pk=payment.customer_id), #
> link resources
> 'value': payment.value, # write here
> 'and_so_on': True, # what do you want
> }
>
> Yes, it does not validate automatically and this example is not restful,
> but you may follow semantic structures like jsonld without any limitation,
> and apply validation in a controller:
>
> @payments.post(accept='application/json')
> def add_payment(ctx):
> form = PaymentForm(data=ctx.body)
> form.is_valid() and form.save(0
> [...]
>
> Where PaymentForm may be a typical Django Form or ModelForm, or even a
> Colander Schema.
> There is more code to write, but implementation is more explitic.
>
> PEP20: Explicit is better than implicit. Simple is better than complex.
> Flat is better than nested. Readability counts. And so on...
>
> BR,
> Marcin
>
>
>
> On Monday, February 27, 2017 at 2:52:46 PM UTC+1, Ankush Thakur wrote:
>>
>> Marcin, that's exactly where I'm stuck! I know endpoints should never be
>> 1:1 serialization of models, but I just don't know how to do that. I mean,
>> I've been able to create endpoints like "/customers/1/payments/" where I
>> use model relationships to generate JSON structures where Customer contains
>> a Payments array field. My Address endpoint seems to be an oddity, as API
>> consumers don't expect the city to contain state and the state to contain
>> country as a JSON structure. How can I add these to the top-level Address
>> entity directly while serialization? That's where I have no answers. Would
>> it be possible for you to point me towards some article that does that?
>> Thanks in advance!
>>
>> Regards,
>> Ankush
>>
>> On Monday, February 27, 2017 at 3:41:49 AM UTC+5:30, marcin@gmail.com
>> wrote:
>>>
>>>
>>>
>>> On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote:
>>>>
>>>> If the relationship chain was even deeper, there would be even more
>>>> nesting, which I feel isn't great for API consumers. What is the best
>>>> practice here to put state and country at the same level as the city?
>>>>
>>>
>>> Just follow REST design.
>>> Forget django models, think about encapsulation.
>>> Think about representation of a resource, not about serializing a
>>> model(s).
>>> Make semantic representations, as good as possible.
>>>
>>> You are not forced to do any nested nasty things. This has nothing to do
>>> with REST api.
>>> You may feel that DRF is limiting you. You'll be on a good path, if so.
>>> :)
>>>
>>> Good luck!
>>> Marcin
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/django-users/ttoJbZJOBnU/unsubscribe.
> To unsubscribe from this group and all its topics, 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/a0b23023-8a5c-4257-ad6d-d72639f85925%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/a0b23023-8a5c-4257-ad6d-d72639f85925%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> 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/CALX%3DrK%2BOxWenwEJwFfHeeY8ipVuWo7Uz4YqoNtHNXEYYz-aRZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Flattening model relationships (in APIs)
I guess this is the library in question:
https://github.com/marcinn/restosaur (took some effort to find it!).
Thanks, if I decide to stick with the API-first approach, I'll use it.
Either way, I've bookmarked it for future use. :-)
Regards,
Ankush Thakur
On Mon, Feb 27, 2017 at 7:53 PM, wrote:
> I was limited by DRF long days ago and I realized that it is not following
> REST architecutre. It does good job in automation in exposing models over
> http, but everything else is way complicated.
> But there were no problem mix both tools in one project. DRF was for "80%"
> of work and my lib for the rest. Downsides? Two libs used to get the job
> done.
>
> Maybe try using DRF's @api_view decorator for function views, and return a
> pure and manually "flattened" dict?
>
> M.
>
>
> On Monday, February 27, 2017 at 3:17:35 PM UTC+1, Ankush Thakur wrote:
>>
>> Hmmm. That's not an answer I wanted to hear, really, but I like it. I'm
>> myself finding DRF too restrictive once you are past the effort-saving
>> magic. Thank you. I might give it up as it's still early days in the
>> project.
>>
>>
>> Regards,
>> Ankush Thakur
>>
>> On Mon, Feb 27, 2017 at 7:43 PM, wrote:
>>
>>> I'm not sure you want to read my answer, really... I've finally stopped
>>> using DRF and wrote own library which is focused on resources, linking and
>>> representations.
>>> I think you can do some customization in DRF, probably you ca declare
>>> custom serializer class, but this is a hard way, IMO.
>>>
>>> I like simple things, so with my lib I can just do something like that:
>>>
>>> payments = api.resource('/payments/')
>>> customer = api.resource('/customers/:pk')
>>>
>>>
>>> @payments.representation
>>> def payment_as_json(payment, ctx):
>>> return {
>>> 'customer_address': payment.customer.address,
>>> 'customer_url': ctx.link_to(customer, pk=payment.customer_id), #
>>> link resources
>>> 'value': payment.value, # write here
>>> 'and_so_on': True, # what do you want
>>> }
>>>
>>> Yes, it does not validate automatically and this example is not restful,
>>> but you may follow semantic structures like jsonld without any limitation,
>>> and apply validation in a controller:
>>>
>>> @payments.post(accept='application/json')
>>> def add_payment(ctx):
>>> form = PaymentForm(data=ctx.body)
>>> form.is_valid() and form.save(0
>>> [...]
>>>
>>> Where PaymentForm may be a typical Django Form or ModelForm, or even a
>>> Colander Schema.
>>> There is more code to write, but implementation is more explitic.
>>>
>>> PEP20: Explicit is better than implicit. Simple is better than complex.
>>> Flat is better than nested. Readability counts. And so on...
>>>
>>> BR,
>>> Marcin
>>>
>>>
>>>
>>> On Monday, February 27, 2017 at 2:52:46 PM UTC+1, Ankush Thakur wrote:
>>>>
>>>> Marcin, that's exactly where I'm stuck! I know endpoints should never
>>>> be 1:1 serialization of models, but I just don't know how to do that. I
>>>> mean, I've been able to create endpoints like "/customers/1/payments/"
>>>> where I use model relationships to generate JSON structures where Customer
>>>> contains a Payments array field. My Address endpoint seems to be an oddity,
>>>> as API consumers don't expect the city to contain state and the state to
>>>> contain country as a JSON structure. How can I add these to the top-level
>>>> Address entity directly while serialization? That's where I have no
>>>> answers. Would it be possible for you to point me towards some article that
>>>> does that? Thanks in advance!
>>>>
>>>> Regards,
>>>> Ankush
>>>>
>>>> On Monday, February 27, 2017 at 3:41:49 AM UTC+5:30,
>>>> marcin@gmail.com wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote:
>>>>>>
>>>>>> If the relationship chain was even deeper, there would be even more
>>>>>> nesting, which I feel isn't great for API consumers. What is the best
>>>>>> practice here to
