Re: anyone solve this problem

[Xavier Ordoquy]

Hi,

The Django REST Framework tutorial, step6 should show you how to do that.
The SnippetViewSet uses the SnippetSerializer to set the current user as the 
owner of the snippet created.

Regards,
Linovia,
Xavier O.

> Le 8 janv. 2021 à 12:43, Praveen chaduvala  a écrit :
> 
> django - how to add current active user as foreign key to the create post 
> model in djangorestframework? - Stack Overflow 
> 
>   
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-rest-framework/3c63250a-22f3-43f7-bcfd-833e422be73an%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-rest-framework/348387A6-FDB6-4FCC-B73B-3560DB524E0D%40linovia.com.

Version 3.12.2 now available

[Xavier Ordoquy]

Django REST framework 3.12.2 is now available on PyPI.
https://pypi.org/project/djangorestframework/

See the release notes for more details: 
https://www.django-rest-framework.org/community/release-notes/#3122 


Thanks to everyone who contributed effort for this release.

Kind Regards,

Xavier.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-rest-framework/d270a51f-4934-46b6-b91b-6b6cbe5e2067n%40googlegroups.com.

Re: 'Article' object is not iterable ,why this error is popping up,while fetching data using primary no

[Xavier Ordoquy]

The question is, what are you trying to do and what outcome are you expecting ?

> Le 4 nov. 2020 à 07:28, Ashutosh Mishra  a écrit 
> :
> 
> So how can I resolve this?
> 
> On Wed 4 Nov, 2020, 11:56 Xavier Ordoquy,  <mailto:xordo...@linovia.com>> wrote:
> Hi,
> 
> Please, paste your code in the mail instead of screenshots, it makes it hard 
> to read.
> In your view, you are passing an Article instance to your serializer along 
> with the many=True keyword which means the serializer will expect an iterable 
> of Articles as the error suggests.
> 
> Regards,
> Xavier O.
> Linovia.
> 
> 
>> Le 4 nov. 2020 à 07:03, Ashutosh Mishra > <mailto:ashutoshmishra...@gmail.com>> a écrit :
>> 
>> whenever i try to fetch data usinng primary key,getting above error
>> models.py
>> 
>> 
>> serializer.py
>> 
>> 
>> view.py
>> 
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django REST framework" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-rest-framework+unsubscr...@googlegroups.com 
>> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-rest-framework/75f76a91-52ed-4cde-887c-26998ab2fe04n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-rest-framework/75f76a91-52ed-4cde-887c-26998ab2fe04n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>> > 11-31-13.png>
> 
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Django REST framework" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/django-rest-framework/2M7lfY2wlZc/unsubscribe
>  
> <https://groups.google.com/d/topic/django-rest-framework/2M7lfY2wlZc/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-rest-framework/4A8683CF-1ACA-4A39-87FC-8254C35C98ED%40linovia.com
>  
> <https://groups.google.com/d/msgid/django-rest-framework/4A8683CF-1ACA-4A39-87FC-8254C35C98ED%40linovia.com?utm_medium=email&utm_source=footer>.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-rest-framework/CAGDmY655NCS_o3wxOCbHam4nYFAbG0o80Auf_%2BeTVBQUaxL6-Q%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/django-rest-framework/CAGDmY655NCS_o3wxOCbHam4nYFAbG0o80Auf_%2BeTVBQUaxL6-Q%40mail.gmail.com?utm_medium=email&utm_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-rest-framework/9255A349-262F-4876-9429-4E1FA8E4543D%40linovia.com.

Re: 'Article' object is not iterable ,why this error is popping up,while fetching data using primary no

[Xavier Ordoquy]

Hi,

Please, paste your code in the mail instead of screenshots, it makes it hard to 
read.
In your view, you are passing an Article instance to your serializer along with 
the many=True keyword which means the serializer will expect an iterable of 
Articles as the error suggests.

Regards,
Xavier O.
Linovia.


> Le 4 nov. 2020 à 07:03, Ashutosh Mishra  a écrit 
> :
> 
> whenever i try to fetch data usinng primary key,getting above error
> models.py
> 
> 
> serializer.py
> 
> 
> view.py
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-rest-framework/75f76a91-52ed-4cde-887c-26998ab2fe04n%40googlegroups.com
>  
> .
>  11-31-13.png>

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-rest-framework/4A8683CF-1ACA-4A39-87FC-8254C35C98ED%40linovia.com.

Re: rest framework

[Xavier Ordoquy]

Hi,

Also make sure you install it first.
Django REST frameworks kickstart 
(https://www.django-rest-framework.org/tutorial/quickstart/#project-setup 
) 
should help you get it working.

Regards,
Xavier O.

> Le 3 nov. 2020 à 22:45, ifthikkarudheen t  a écrit :
> 
> First i have tried with that.. that too doesn't work man... 
> 
> On Wed, 4 Nov 2020, 03:07 Abdulrahman Alotaibi,  > wrote:
> Hi Ifthikkarudheen,
> 
> When you import 'rest-frameworm' inside .py files you need to use 
> 'rest_framework' with an Underscore not a dash.
> 
> Sincerely,
> Abdulrahman
> 
> On Tue, Nov 3, 2020, 2:40 PM ifthikkarudheen t  > wrote:
> i ' m unable  to add rest framework  i get this error
> 
>   module = import_module(entry)
>   File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 1014, in _gcd_import
>   File "", line 991, in _find_and_load
>   File "", line 973, in _find_and_load_unlocked
> ModuleNotFoundError: No module named 'rest-framework'
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-rest-framework/f4106175-8ace-44a4-8793-606fd729ea59n%40googlegroups.com
>  
> .
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-rest-framework/CAMCoxY8zkLexarruVTvcg_hjdadUNqdDT0wwKhAvU3nq9z_Tzg%40mail.gmail.com
>  
> .
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-rest-framework/CAD0H1LoTXd0JywXLNBnmCk9rHbEv23s0Y4pWgDX8sn%2BkYiw1tQ%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-rest-framework/E9FA6A86-7E62-4E67-832D-68DB96A6A4FC%40linovia.com.

Re: Django is getting ASYNC, what about DRF ?

[Xavier Ordoquy]

What about it ?
I don’t think DRF we use anything that is async incompatible outside Django 
itself.

Regards,
Xavier O.
Linovia.

> Le 22 nov. 2019 à 14:10, Dennis  a écrit :
> 
> As per Andrew Godwin presentation at DjangoCon2019 the plan is:
> - 3.0 --> ASGI server, ASGIHandler
> - 3.1 --> Async Views
> - 3.2/4.0 --> Async ORM
> 
> What about DRF ?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-rest-framework/774dbd4d-b368-4dd5-87b6-d660f137fa3d%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-rest-framework/375CA8DD-6326-42D3-8D8D-BF043C165D0C%40linovia.com.

Re: [feature request] permission required decorator for drf api views

[Xavier Ordoquy]

Hi,

Class based views have a permission_classes setting 
(https://www.django-rest-framework.org/api-guide/permissions/#setting-the-permission-policy
 
)
 and function based views have a @permission_classes decorator 
(https://www.django-rest-framework.org/api-guide/views/#api-policy-decorators 
).
What is currently missing that would require another decorator ?

Regards,
Xavier O.

> Le 22 juil. 2019 à 13:29, Kush Goyal  a écrit :
> 
> Django has a handy decorator to check permissions on a view function. [1]
> 
> I request this decorator to be included in DRF.
> 
> [1] 
> https://docs.djangoproject.com/en/2.2/topics/auth/default/#the-permission-required-decorator
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-rest-framework/d7babd11-0e01-48c4-99fe-e66fc2383c6b%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-rest-framework/AFC088A7-2EC4-46C4-9D5E-DCFBE06B40E5%40linovia.com.

Re: perform_create never called, despite being recommended by docs

[Xavier Ordoquy]

Well, this looks like you did a lot of unpasted changes which most likely 
alters the default behavior.
By default, request is already set to the serializer's context.

This being said, if the request is valid and it’s a creation, perform_create is 
called.
If it’s not, try to remove parts of your custom code until you find the culprit.

Good luck,
Xavier.


> Le 6 avr. 2019 à 21:45, 'Alexander Halford' via Django REST framework 
>  a écrit :
> 
> Hi,
> 
> The response code is indeed an error, because the database throws an 
> integrity error, since it doesn’t get a value for a required field.
> 
> However, I have managed to get this to work by overriding the serialiser’s 
> create method, and passing the request through as context. In this case, the 
> *exact same* request worked, so I’m fairly confident that the request is fine.
> 
> Regards,
> 
> Alex
> 
>> On 6 Apr 2019, at 20:43, Xavier Ordoquy > <mailto:xordo...@linovia.com>> wrote:
>> 
>> Hi,
>> 
>> Did you first ensure the client’s request is valid ? What’s the response 
>> code ?
>> Most likely, the request is invalid preventing the perform_create to be 
>> called.
>> 
>> Regards,
>> Xavier.
>> 
>>> Le 6 avr. 2019 à 20:48, 'Alexander Halford' via Django REST framework 
>>> >> <mailto:django-rest-framework@googlegroups.com>> a écrit :
>>> 
>>> Here is a link to the code that I was using:
>>> 
>>> https://paste.ubuntu.com/p/5SMQJxg59d/ 
>>> <https://paste.ubuntu.com/p/5SMQJxg59d/>
>>> 
>>> I put a print statement in “perform_create”, and it really seems like it is 
>>> never called...
>>> 
>>>> On 6 Apr 2019, at 18:10, Joseph Peck >>> <mailto:joe.r.p...@gmail.com>> wrote:
>>>> 
>>>> Do you have a field set up in the model to catch the value?
>>>> 
>>>> On Sat, Apr 6, 2019, 10:09 AM Joseph Peck >>> <mailto:joe.r.p...@gmail.com>> wrote:
>>>> It does indeed get called. I suggest double checking other factors 
>>>> presented in the tutorial. I tested it during the tutorial, used it 
>>>> recently, customized it recently, and it's going to be the first thing I 
>>>> go to after breakfast.
>>>> 
>>>> On Sat, Apr 6, 2019, 8:09 AM 'Alexander Halford' via Django REST framework 
>>>> >>> <mailto:django-rest-framework@googlegroups.com>> wrote:
>>>> I have a ModelViewset, and a ModelSerializer. When creating an object, 
>>>> they should set the 'uploaded_by' attribute to be the user in the request.
>>>> 
>>>> The docs suggest here 
>>>> <https://www.django-rest-framework.org/api-guide/generic-views/#genericapiview>
>>>>  that the best way of doing this is to override perform_create in the 
>>>> viewset, like so:
>>>> 
>>>> class FooViewset(viewsets.ModelViewset):
>>>> serializer_class = FooSerializer
>>>> 
>>>> def perform_create(self, serializer):
>>>> serializer.save(uploaded_by=self.request.user)
>>>> 
>>>>  
>>>> However, this does not work. I did some debugging, and perform_create is 
>>>> not actually called.
>>>> 
>>>> I am faintly aware that this can be done in the create method of the 
>>>> serializer, by passing the request as context from the viewset, but the 
>>>> above looks neater, and is the method recommended in the docs... Why is it 
>>>> not working?
>>>> 
>>>> -- 
>>>> You received this message because you are subscribed to the Google Groups 
>>>> "Django REST framework" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>>> email to django-rest-framework+unsubscr...@googlegroups.com 
>>>> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
>>>> For more options, visit https://groups.google.com/d/optout 
>>>> <https://groups.google.com/d/optout>.
>>>> 
>>>> -- 
>>>> You received this message because you are subscribed to the Google Groups 
>>>> "Django REST framework" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>>> email to django-rest-framework+unsubscr...@googlegroups.com 
>>>> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
>>&

Re: perform_create never called, despite being recommended by docs

[Xavier Ordoquy]

Hi,

Did you first ensure the client’s request is valid ? What’s the response code ?
Most likely, the request is invalid preventing the perform_create to be called.

Regards,
Xavier.

> Le 6 avr. 2019 à 20:48, 'Alexander Halford' via Django REST framework 
>  a écrit :
> 
> Here is a link to the code that I was using:
> 
> https://paste.ubuntu.com/p/5SMQJxg59d/ 
> 
> 
> I put a print statement in “perform_create”, and it really seems like it is 
> never called...
> 
>> On 6 Apr 2019, at 18:10, Joseph Peck > > wrote:
>> 
>> Do you have a field set up in the model to catch the value?
>> 
>> On Sat, Apr 6, 2019, 10:09 AM Joseph Peck > > wrote:
>> It does indeed get called. I suggest double checking other factors presented 
>> in the tutorial. I tested it during the tutorial, used it recently, 
>> customized it recently, and it's going to be the first thing I go to after 
>> breakfast.
>> 
>> On Sat, Apr 6, 2019, 8:09 AM 'Alexander Halford' via Django REST framework 
>> > > wrote:
>> I have a ModelViewset, and a ModelSerializer. When creating an object, they 
>> should set the 'uploaded_by' attribute to be the user in the request.
>> 
>> The docs suggest here 
>> 
>>  that the best way of doing this is to override perform_create in the 
>> viewset, like so:
>> 
>> class FooViewset(viewsets.ModelViewset):
>> serializer_class = FooSerializer
>> 
>> def perform_create(self, serializer):
>> serializer.save(uploaded_by=self.request.user)
>> 
>>  
>> However, this does not work. I did some debugging, and perform_create is not 
>> actually called.
>> 
>> I am faintly aware that this can be done in the create method of the 
>> serializer, by passing the request as context from the viewset, but the 
>> above looks neater, and is the method recommended in the docs... Why is it 
>> not working?
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django REST framework" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-rest-framework+unsubscr...@googlegroups.com 
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django REST framework" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-rest-framework+unsubscr...@googlegroups.com 
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composable permissions question

[Xavier Ordoquy]

Hi,

We might do that but handling None a is side effect that is not supported.
Documentation 
(https://www.django-rest-framework.org/api-guide/permissions/#custom-permissions)
 says:

The methods should return True if the request should be granted access, and 
False otherwise.


Regards,
Xavier Ordoquy


> Le 22 févr. 2019 à 08:43, Frank Bohnsack  a écrit :
> 
> One question again:
> 
> earlier versions of DRF permissions does support None returns values as well 
> and handles None like False. The New composable permissions will raise an 
> error here:
> 
> unsupported operand type(s) for &: 'bool' and 'NoneType'
> 
> Would it be possible to add None support again?
> 
> Regards
> Frank
> 
> Am Mittwoch, 31. Oktober 2018 19:49:38 UTC+1 schrieb Frank Bohnsack:
> While trying out the new composable permission feature, I have the following 
> problem:
> 
> >>> IsAuthenticated & IsStaff | IsAuthenticatedWithTwoFactor & IsCustomer
> Traceback (most recent call last):
>   File "/usr/lib/python3.6/code.py", line 91, in runcode
> exec(code, self.locals)
>   File "", line 1, in 
> TypeError: unsupported operand type(s) for |: 'OperandHolder' and 
> 'OperandHolder'
> >>>
> 
> It seems that is posible to compose like 
> 
> (IsAuthenticated | IsStaff) & IsAuthenticatedWithTowFactor
> 
> but compose two composed permissions will not work :-(
> 
> Is it a feature or whats wrong in my code?
> 
> Regards
> Frank
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation for earlier version of DRF 3.X

[Xavier Ordoquy]

Hi,

You will need to:
- checkout the tag
- installing the dependencies found in 
requirements/requirements-documentation.txt and 
requirements/requirements-testing.txt
- generate the documentation with mkdocs build

Regards,
Xavier O.

> Le 30 janv. 2019 à 12:29, ankGT  a écrit :
> 
> I understand that the current version of DRF is at 3.9. However, I am still 
> using version 3.7.7, and would like to view the documentation from this 
> version. 
> 
> How can I do this? Normally for other projects theres a way to switch between 
> versions, but for the life of me I cannot find this here. Am I missing 
> something obvious?
> 
> Thank you!
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: import error in tutorial quickstart

[Xavier Ordoquy]

To avoid creating another tutorial directory

Regards,
Xavier O.

> Le 29 nov. 2018 à 18:59, vijay.b.seh...@gmail.com a écrit :
> 
> Why is . used after djan*** tutorial '.' ? 
> 
> On Monday, March 13, 2017 at 11:50:08 AM UTC+5:30, Xavier Ordoquy wrote:
> Hi madame,
> 
> You have missed the trailing dot in this part in the tutorial:
> 
> django-admin.py startproject tutorial .  # Note the trailing '.' character
> 
> Regards,
> Xavier Ordoquy,
> Linovia.
> 
> 
>> Le 13 mars 2017 à 07:06, Tony Wang gmail.com 
>> <http://gmail.com/>> a écrit :
>> 
>> Hi Guys
>> 
>> Have you guys tested the code in quickstart? There seems be to an import 
>> error . It will run well when removed tutorial (Marked italic and red).
>> 
>> 
>> Environment:
>> 
>> 
>> Request Method: GET
>> Request URL: http://10.211.55.12:8000/users/1/ 
>> <http://10.211.55.12:8000/users/1/>
>> 
>> Django Version: 1.8.13
>> Python Version: 2.7.12
>> Installed Applications:
>> ('django.contrib.admin',
>>  'django.contrib.auth',
>>  'django.contrib.contenttypes',
>>  'django.contrib.sessions',
>>  'django.contrib.messages',
>>  'django.contrib.staticfiles',
>>  'rest_framework',
>>  'restapp')
>> Installed Middleware:
>> ('django.contrib.sessions.middleware.SessionMiddleware',
>>  'django.middleware.common.CommonMiddleware',
>>  'django.middleware.csrf.CsrfViewMiddleware',
>>  'django.contrib.auth.middleware.AuthenticationMiddleware',
>>  'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
>>  'django.contrib.messages.middleware.MessageMiddleware',
>>  'django.middleware.clickjacking.XFrameOptionsMiddleware',
>>  'django.middleware.security.SecurityMiddleware')
>> 
>> 
>> Traceback:
>> File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py" 
>> in get_response
>>   119. resolver_match = resolver.resolve(request.path_info)
>> File "/usr/local/lib/python2.7/dist-packages/django/core/urlresolvers.py" in 
>> resolve
>>   365. for pattern in self.url_patterns:
>> File "/usr/local/lib/python2.7/dist-packages/django/core/urlresolvers.py" in 
>> url_patterns
>>   401. patterns = getattr(self.urlconf_module, "urlpatterns", 
>> self.urlconf_module)
>> File "/usr/local/lib/python2.7/dist-packages/django/core/urlresolvers.py" in 
>> urlconf_module
>>   395. self._urlconf_module = import_module(self.urlconf_name)
>> File "/usr/lib/python2.7/importlib/__init__.py" in import_module
>>   37. __import__(name)
>> File "/root/rest_example/rest_example/urls.py" in 
>>   18. from restapp import views
>> File "/root/rest_example/restapp/views.py" in 
>>   3. from tutorial.quickstart.serializers import UserSerializer, 
>> GroupSerializer
>> 
>> Exception Type: ImportError at /users/1/
>> Exception Value: No module named tutorial.quickstart.serializers
>> 
>> 
>> 
>> 
>> http://www.django-rest-framework.org/tutorial/quickstart/ 
>> <http://www.django-rest-framework.org/tutorial/quickstart/>
>> 
>> from django.contrib.auth.models import User, Group
>> from rest_framework import viewsets
>> from tutorial.quickstart.serializers import UserSerializer, GroupSerializer
>> 
>> 
>> class UserViewSet(viewsets.ModelViewSet):
>> """
>> API endpoint that allows users to be viewed or edited.
>> """
>> queryset = User.objects.all().order_by('-date_joined')
>> serializer_class = UserSerializer
>> 
>> 
>> class GroupViewSet(viewsets.ModelViewSet):
>> """
>> API endpoint that allows groups to be viewed or edited.
>> """
>> queryset = Group.objects.all()
>> serializer_class = GroupSerializer
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django REST framework" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-rest-framework+unsubscr...@googlegroups.com <>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bulk validation and creation

[Xavier Ordoquy]

Hi,

This is an issue I faced 2 or 3 years ago.
I ended up rewriting most of the serializer with custom code.
I checked a few things by myself first and used bulk inserts.
If everything went fine, good, I could send back how happy the server was 
within a few seconds.
If there was errors, I did fallback on a more complex and time consuming check 
to see where the errors could be and return a meaningful message.
Unfortunately this is private code and I’m not allowed to share it.

Regards,
Xavier O.

> Le 19 nov. 2018 à 10:00, Tom Gowland  a écrit :
> 
> Hello all,
> 
> I hope this hasn't been asked before here (I've had a search and couldn't 
> find anything!).
> 
> I am running a reasonably large POST operation on my API (around 32,000 JSON 
> objects). 
> Unfortunately, processing this POST takes more than a minute to complete with 
> the longest steps being the validation and creation of the entries.
> 
> When I use django-extensions with the --print-sql flag, I see that each 
> validation step is done as a separate database query. The same is true for 
> each object creation.
> I'm guessing that if I did each of these operations in one query then things 
> would be much faster but I can't find any information on how to do it!.
> 
> Please have a look at my SO post for the source code: 
> https://stackoverflow.com/questions/53364738/django-rest-framework-serialization-post-is-slow/53369867#53369867
> 
> Many thanks,
> Tom
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Invalid source attribute does not throw an error

[Xavier Ordoquy]

Hi

> Le 19 nov. 2018 à 09:31, andreashanauska via Django REST framework 
>  a écrit :
> 
> Hi,
> 
> ok, understood that. But at some point python would need to call that 
> property/method whatever. And if it does not exist, python would thrown an 
> error.

It wouldn’t unless you use some specific class that implements that behavior.

>>> class Demo:
...   pass
... 
>>> d = Demo()
>>> d.a
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'Demo' object has no attribute 'a'
>>> d.a = 1
>>> d.a
1
>>> 


Regards,
Xavier O.


> So why this error is not raised?
> 
> Regards
> Andi
> 
> Am Donnerstag, 15. November 2018 18:08:36 UTC+1 schrieb Xavier Ordoquy:
> Hi,
> 
> There are no errors because the value gets map to the instance’s « abc ».
> It could be a property with setters / getters that process the value and fill 
> some of the model’s field (or the other way around). For example, you could 
> have a write only property « password » that takes a password, hash/salt it 
> and sets it to the hashed_password field. It could also be some reporting 
> computed live for a read only property.
> 
> Regards,
> Xavier.
> 
> 
>> Le 15 nov. 2018 à 16:43, andreashanauska via Django REST framework 
>> googlegroups.com <http://googlegroups.com/>> a écrit :
>> 
>> Hi,
>> 
>> recently i deployed an API using the following serializers:
>> 
>> class SimpleMotorTypeSerializer(serializers.ModelSerializer):
>> 
>> class Meta:
>> model = MotorType
>> fields = ('url',
>>   'id',
>>   'customer_part_number',
>>   )
>> 
>> class MotorSerializer(serializers.ModelSerializer):
>> motor_type = SimpleMotorTypeSerializer(source='abc', read_only=True)
>> 
>> class Meta:
>> model = Motor
>> fields = ('url',
>>   'id',
>>   'motor_type',
>>   ...)
>> 
>> The problem is with the source agrument. I just misspelled the source string 
>> (inidicated here with "abc", which does not exist).
>> My tests didn't throw an error because there is no error thrown at all.
>> 
>> So i am interested how i could avoid this in future (because typing errors 
>> are a human thing). Probably testing each single attribute in my JSON 
>> response.
>> 
>> But mainly i am asking: 
>> Why there is no error raised for a non existing "abc" source?
>> 
>> Greets
>> Andi
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django REST framework" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-rest-framework+unsubscr...@googlegroups.com <>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Invalid source attribute does not throw an error

[Xavier Ordoquy]

Hi,

There are no errors because the value gets map to the instance’s « abc ».
It could be a property with setters / getters that process the value and fill 
some of the model’s field (or the other way around). For example, you could 
have a write only property « password » that takes a password, hash/salt it and 
sets it to the hashed_password field. It could also be some reporting computed 
live for a read only property.

Regards,
Xavier.


> Le 15 nov. 2018 à 16:43, andreashanauska via Django REST framework 
>  a écrit :
> 
> Hi,
> 
> recently i deployed an API using the following serializers:
> 
> class SimpleMotorTypeSerializer(serializers.ModelSerializer):
> 
> class Meta:
> model = MotorType
> fields = ('url',
>   'id',
>   'customer_part_number',
>   )
> 
> class MotorSerializer(serializers.ModelSerializer):
> motor_type = SimpleMotorTypeSerializer(source='abc', read_only=True)
> 
> class Meta:
> model = Motor
> fields = ('url',
>   'id',
>   'motor_type',
>   ...)
> 
> The problem is with the source agrument. I just misspelled the source string 
> (inidicated here with "abc", which does not exist).
> My tests didn't throw an error because there is no error thrown at all.
> 
> So i am interested how i could avoid this in future (because typing errors 
> are a human thing). Probably testing each single attribute in my JSON 
> response.
> 
> But mainly i am asking: 
> Why there is no error raised for a non existing "abc" source?
> 
> Greets
> Andi
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composable permissions question

[Xavier Ordoquy]

Hi,

It’s more a bug in DRF.
Could you open an issue about that so we can keep it on our radars ?

Regards,
Xavier,
Linovia.

> Le 31 oct. 2018 à 19:49, Frank Bohnsack  a écrit :
> 
> While trying out the new composable permission feature, I have the following 
> problem:
> 
> >>> IsAuthenticated & IsStaff | IsAuthenticatedWithTwoFactor & IsCustomer
> Traceback (most recent call last):
>   File "/usr/lib/python3.6/code.py", line 91, in runcode
> exec(code, self.locals)
>   File "", line 1, in 
> TypeError: unsupported operand type(s) for |: 'OperandHolder' and 
> 'OperandHolder'
> >>>
> 
> It seems that is posible to compose like 
> 
> (IsAuthenticated | IsStaff) & IsAuthenticatedWithTowFactor
> 
> but compose two composed permissions will not work :-(
> 
> Is it a feature or whats wrong in my code?
> 
> Regards
> Frank
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Basic understanding / custom field - point of access

[Xavier Ordoquy]

Hi,

It’s a bit more complex than that.

Content négociation along with renderers and parsers will move the data from 
the HTTP body into basic python types (int / floats / strings).
Serializers will move those basic types from and to more complex ones 
(DateTimes, Decimals, Django models / querysets).

hopes this will help.

Regards,
Xavier,
Linovia.

> Le 30 oct. 2018 à 16:55, 'enricoba' via Django REST framework 
>  a écrit :
> 
> Hi, 
> 
> I am fairly new to Django REST framework, but mid experienced with native 
> Django. First I have a basic question regarding serializers (see picture - 
> using the REST framework tutorial info). For my understanding the serializer 
> transforms a Django queryset into a „readable“ JSON. Therefore, I am not sure 
> what is happening in step 7 and 8 (hoping my assumptions are correct). Is the 
> serializer defining which fields of the querysets shall be serialized? So I 
> don‘t know why it has to look into Models again.
> 
> Beside of this general question, I have a special setup of data. In addition 
> to storing raw data, I store hash strings of my payload in each record (own 
> field "checksum"). I do this to notice data manipulation on database level 
> (there is a pepper from the application layer included). However, I would 
> like to add a custom field to all of my API calls that provides a bool 
> telling that the payload was not manipulated (compare payload + pepper with 
> hash). As from what I have learned until now, I could do this by adding a 
> custom field to the Model that I can call via the serializer. Unfortunately, 
> when doing so I only can access the Model object, not the Manager of the 
> Model. Therefore, I can only explicitly call model fields, but not generic. 
> Now my question is if this is even the correct point of access? Or should / 
> can I deal with this on the view level?
> 
> Thanks for any advice!
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Advice on disabling validators for Nested serializers

[Xavier Ordoquy]

Hi,

I wrote about this a while ago.
Everything should be explained here: 
https://medium.com/django-rest-framework/dealing-with-unique-constraints-in-nested-serializers-dade33b831d9

Regards,
Xavier O.
Linovia.

> Le 17 août 2018 à 23:41, Arjun Nambiar  a écrit :
> 
> Hi Ryan,
> 
> It is basically a serializer validation error stating that "IP already 
> exists" so there is no stack trace. I need to somehow disable unique key 
> validation check for IPs when being used as a nested serializer in IPGroups.
> 
> On Friday, 17 August 2018 11:31:26 UTC-7, Ryan Kilby wrote:
> Hi Arjun,
> 
> It would be helpful to see the actual stack trace associated with the error. 
> 
> On Thursday, August 16, 2018 at 12:02:02 PM UTC-7, Arjun Nambiar wrote:
> My models.py
> 
> from django.db import models
> from netfields import InetAddressField, CidrAddressField, NetManager
> 
> class IP(models.Model):
> """
> Stores IP Objects
> """
> # name is the reverse lookup of an IP if it exists else it is IP_
> name = models.CharField(max_length=50, unique=True)
> value = InetAddressField(unique=True)
> 
> objects = NetManager()
> 
> def __unicode__(self):
> return f'{self.name }'
> 
> 
> class CIDR(models.Model):
> """
> Stores CIDR Objects
> """
> # name of a subnet is NETWORK_
> name = models.CharField(max_length=50, unique=True)
> value = CidrAddressField(unique=True)
> 
> objects = NetManager()
> 
> def __unicode__(self):
> return f'{self.name }'
> 
> 
> class IPGroup(models.Model):
> """
> Stores IP Groups
> """
> name = models.CharField(max_length=50, unique=True)
> ips = models.ManyToManyField(IP, through=IPGroupToIP)
> cidrs = models.ManyToManyField(CIDR, through=IPGroupToCIDR)
> 
> def __unicode__(self):
> return f'{self.name }'
> 
> My serializers.py
> 
> class IPSerializer(serializers.ModelSerializer):
> class Meta:
> model = IP
> fields = ['id', 'name', 'value']
> 
> 
> class CIDRSerializer(serializers.ModelSerializer):
> class Meta:
> model = CIDR
> fields = ['id', 'name', 'value']
> 
> 
> class IPGroupSerializer(serializers.ModelSerializer):
> """
> This Serializer is responsible for parsing IPGroup POST Request.
> It validates the JSON Body and throws error if any of the fields does 
> not meet requirements.
> """
> ips = IPSerializer(many=True)
> cidrs = CIDRSerializer(many=True)
> 
> class Meta:
> model = IPGroup
> depth = 1
> fields = '__all__'
> 
> def validate(self, data):
> mandatory_list = ['ips', 'cidrs']
> if not any(data[item] for item in mandatory_list):
> raise serializers.ValidationError("Atleast one of the fields(IP, 
> Subnets) should be present")
> 
> if ' ' in data['name']:
> raise serializers.ValidationError("IPGroups cannot have spaces in 
> their names")
> 
> return data
> 
> @transaction.atomic()
> def create(self, validated_data):
> # Pop out ips, subnet since these are M2M and have to be created 
> separately
> ips_data = validated_data.pop('ips', None)
> cidrs_data = validated_data.pop('cidrs', None)
> 
> # First create an IPGroup with the required name
> ip_group = IPGroup.objects.create(name=validated_data['name'])
> 
> # Now create the M2M relationships
> if ips_data:
> for ip in ips_data:
> # Get the ip object id if already created or create it on the 
> fly and save it
> ip_obj, created = IP.objects.get_or_create(name=ip['name'], 
> value=ip['value'])
> IPGroupToIP.objects.create(ip_group_id=ip_group.id 
> , ip_id=ip_obj.id )
> 
> if cidrs_data:
> for cidr in cidrs_data:
> # Get the subnet object id if already created or create it on 
> the fly and save it
> cidr_obj, created = 
> CIDR.objects.get_or_create(name=f"NETWORK_{cidr['name']}", 
> value=cidr['value'])
> IPGroupToCIDR.objects.create(ip_group_id=ip_group.id 
> , cidr_id=cidr_obj.id )
> 
> return ip_group
> 
> 
> My views.py
> class IPGroupCreateView(generics.CreateAPIView):
> queryset = IPGroup.objects.get_queryset()
> serializer_class = IPGroupSerializer
> 
> This however keeps giving me a validation error saying that IP or CIDR 
> already exists. However, I am using the get_or_create to create IPs and CIDRs 
> and hence should not be getting this error. I am assuming that this happening 
> because of the nested model serializer's unique field validation kicking in. 
> How would I disable the unique key validation for IPs and CIDRs only when i 
> am creating an IPGroup ?
> 
> 
> -- 
> You received this mess

Re: ValidationError in Snippets tutorial

[Xavier Ordoquy]

Validation is only intended from external data (basic Python types) to more 
complex structures (Django models). This happens during deserialization.
Here, you are already providing a complex model like it was basic Python types.

In order to work this around, it should be:

data = {
‘owner_id’: 1,
‘code’: ‘foo’
}
ser = SnippetSerializer(data=snippet, many=False)
ser.is_valid(raise_exception=True)

Regards,
Xavier Ordoquy,
Linovia.

> Le 7 mai 2018 à 12:36, Rainer Hihn  a écrit :
> 
> I checked out the Snippets tutorial and set it up working. Then I tried do a 
> simple validation but I'm getting this error and I'm not sure why. 
> The serializer is the same from the tutorial: 
> <https://github.com/encode/rest-framework-tutorial/blob/master/snippets/serializers.py>
> 
> from snippets.models import *
> from snippets.serializers import *
> 
> snippet = Snippet()
> snippet.owner_id = 1
> snippet.code = "foo"
> snippet.save()
> 
> ser = SnippetSerializer(data=snippet, many=False)
> ser.is_valid(raise_exception=True)
> ---
> ValidationError   Traceback (most recent call last)
>  in ()
> > 1 ser.is_valid(raise_exception=True)
> 
> ~/.virtualenvs/rest/lib/python3.6/site-packages/rest_framework/serializers.py 
> in is_valid(self, raise_exception)
> 242 
> 243 if self._errors and raise_exception:
> --> 244 raise ValidationError(self.errors)
> 245 
> 246 return not bool(self._errors)
> 
> ValidationError: {'non_field_errors': ['Invalid data. Expected a dictionary, 
> but got Snippet.']}
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Optional trailing slashes in Routers

[Xavier Ordoquy]

The solution proposed on SO looks sensible to me.
I think the optional trailing slash is a bad idea because you won’t have a 
unique identifier for representation any longer.

Regards,
Xavier Ordoquy,
Linovia;

> Le 13 avr. 2018 à 11:39, German Prostakov  a écrit :
> 
> Is it possible to do without such workaround suggested on SO: 
> https://stackoverflow.com/questions/46163838/how-can-i-make-a-trailing-slash-optional-on-a-django-rest-framework-simplerouter?
> Is it planned to allow optional trailing space in Routers? I think I'm not 
> the only one who thinks this is a lack of convenience, especially if you 
> switch your backend to Django and you had optional trailing slashes in routes 
> in previous backend framework (Express.js)
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any good practice to caching ListAPIView?

[Xavier Ordoquy]

Hi,

The message says that you are trying to pickle the response - which is done 
through the cache.set(key, res,60) call - while the response is not 
rendered yet.
This should be fixed by accessing response.content before calling the 
cache.set

Regards,
Xavier Ordoquy,
Linovia.

Le mardi 20 mars 2018 13:33:33 UTC+1, Fover a écrit :
>
> I try to cache ListAPIView.I find solution on stackoverflow:
>
> from django.utils.decorators import method_decoratorfrom 
> django.views.decorators.cache import cache_page
> class ProductListAPIView(generics.ListAPIView):
> serializer_class = ProductSerializer
>
> @method_decorator(cache_page(60))
> def dispatch(self, *args, **kwargs):
> return super(ProductListAPIView, self).dispatch(*args, **kwargs)
>
> It works.
> But in my project ,the client make GET request with timestamp, it will be 
> cached , but other user can not hit this cache almost.
>
> I try to remove timestamp, my code is:
>
> class ProductListAPIView(generics.ListAPIView):
> serializer_class = ProductSerializer
>
> def dispatch(self, request, *args, **kwargs):
> key=gen_cache_key(request)
> print(key)
> res=cache.get(key)
> if res:
> return res
> res= super().dispatch(request, *args, **kwargs)
> cache.set(key,res,60)
> return res
> def gen_cache_key(request):
> params=request.GET
> key=request.path
> for x in params.lists():
> if x[0]!='timestamp':
> key+=str(x[0])
> key+=str(x[1][0])
> return key
>
> emmm. It raise an error. ContentNotRenderedError >> The response content 
> must be rendered before it can be pickled.
>
> How to deal with it ?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DateTimeField serializer different values specifying 'DATETIME_FORMAT': "%Y-%m-%dT%H:%M:%S%z",

[Xavier Ordoquy]

Hi,

> Le 14 mars 2018 à 14:53, Daviddd  a écrit :
> 
> Hello All,
> 
> I'm using Django 2.0.1 and DRF djangorestframework==3.7.7 with USE_TZ = True.
> 
> The model field is declared as
> 
> modified = models.DateTimeField(auto_now=True)
> 
> 
> Serializer
> 
> **
> class Meta:
> fields = ('id', 'url', 'owners', 'type', 'title', 'abstract', 
> 'created', 'keywords',  'username', 'password', 'modified', )
> read_only_fields = ('owners', 'type', 'title', 'abstract', 'keywords')
> extra_kwargs = {
> 'username': {'write_only': True},
> 'password': {'write_only': True}
> }
> 
> 
> 
> My local time is 2018-03-14T13:53:17 (UTC+1), I modify the record:
> 
> from models import model
> m = model.objects.get(pk=1)
> m.save()
> 
> vars(m) result is:
> **
>  'modified': datetime.datetime(2018, 3, 14, 12, 53, 17, 168977, tzinfo=),
> **
> 
> 
> In the DB the modified date is 2018-03-14 12:53:17.168977+00 (UTC). 
> 
> Now the API returns the JSON as:
> 
> "modified": "2018-03-14T13:53:17.168977+01:00",
> 
> Shouldn’t be 2018-03-14T12:53:17.168977+01:00?

Either it’s 13:53 with UTC+1 or 12:53 with UTC+0.
Both are the same time, the only difference is the timezone.
Same value, different representation.

> 
> While adding:
> 
> REST_FRAMEWORK = {
> 'DATETIME_FORMAT': "%Y-%m-%dT%H:%M:%S%z",
> 
> **
> 
> 
> 
> returns as  "modified": "2018-03-14T12:53:17+",
> 
> Ideas?
> 
> Thanks!
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: query param detail route django rest returns 500

[Xavier Ordoquy]

It looks like you are using `query_param` to filter your dataset. The 
detail_route is based on the filtered dataset. However, there’s no reason the 
get_object returns more than one item. Maybe the project overrides the 
get_object in a way that breaks.

Regards,
Xavier Ordoquy,
Linovia.

> Le 16 févr. 2018 à 15:38, sa...@magicboxasia.com a écrit :
> 
> Hi
> I am fully understand the usage of the Django REST. Then I would like to 
> discuss the mechanic of it in here since. Github template mentions me that.
> First picture is `detail route`
> Second picture is `list route + filter`
> Third one is `error`
> 
> Today my colleague he tries add `query_param` to the `detail route` which I 
> have never tried.
> He found that Django REST returns him `500`
> 
> Why `detail route` still read the `query_param`?
> Thanks
> Sarit
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
>  21.33.45.png>

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: getting 401 for invalid token not 403

[Xavier Ordoquy]

Hi,

The documentation also says that it will use the first scheme to figure out 
whether it should respond a 401 or 403 and SessionAuthentication will return a 
403 upon unauthenticated unauthorized request.
I provided the links in a similar SO response.

Regards,
Xavier,
Linovia.


> Le 7 févr. 2018 à 08:29, Hamed Salimian  a écrit :
> 
> Hi
> in documents you is mentioned "By default this exception results in a 
> response with the HTTP status code "401 Unauthenticated", but it may also 
> result in a "403 Forbidden" response, depending on the authentication scheme 
> in use."
> 
> I am using tokenauthenticate and getting 403 for invalid token instead of 
> 401. in the official docs or other docs i couldn't find the way to handle 
> this. below is my scheme, is there any problem?
> 
> tnx
> 
> REST_FRAMEWORK = {
> 'DEFAULT_AUTHENTICATION_CLASSES': (
> 'rest_framework.authentication.SessionAuthentication',
> 'rest_framework.authentication.TokenAuthentication',
> ),
> 'DEFAULT_PERMISSION_CLASSES': (
> 'rest_framework.permissions.IsAuthenticated',
> ),
> 'UPLOADED_FILES_USE_URL': False,
> 
> 'DEFAULT_PAGINATION_CLASS': None,
> 'PAGE_SIZE': DEFAULT_PAGE_SIZE,  # For views using PageNumberPagination
> }
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django REST Framework

[Xavier Ordoquy]

This was a compatibility layer to be compatible with Django < 1.10. Since it’s 
not supported any longer it has been removed.

> Le 30 janv. 2018 à 11:06, Xavier Ordoquy  a écrit :
> 
> Hi,
> 
> I don’t think it ever had. What are you referring to ?
> 
> Regards,
> Xavier.
> 
>> Le 30 janv. 2018 à 11:03, Cynthia Simiyu > <mailto:cynthia.sim...@financeplan.biz>> a écrit :
>> 
>> compat.py missing def set_many in version 3.7.7, why?
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django REST framework" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-rest-framework+unsubscr...@googlegroups.com 
>> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: Django REST Framework

[Xavier Ordoquy]

Hi,

I don’t think it ever had. What are you referring to ?

Regards,
Xavier.

> Le 30 janv. 2018 à 11:03, Cynthia Simiyu  a 
> écrit :
> 
> compat.py missing def set_many in version 3.7.7, why?
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: How to build an API where the endpoints don't quite match the underlying database schemata?

[Xavier Ordoquy]

Hi,

> Le 23 janv. 2018 à 00:57, JI Ioannidis  a écrit :
> 
> The tutorial, and pretty much everything else I have found, assumes that the 
> models defined in models.py map one-to-one to database tables. I need to 
> build an API for a service that uses the database, of course, but the 
> endpoints I want to present do not correspond to the database tables. Can 
> someone point me to where in the documentation this would be covered? FWIW, 
> the database is Postgres, so I can't create views for that, as views are not 
> mutable in postgres.

Anything that’s before ModelSerializer in 
http://www.django-rest-framework.org/api-guide/serializers/ applies to non 
model serialization.
Same goes for step 1 of the tutorial before « Using ModelSerializer ».
A huge part of the documentation covers ModelSerializer because it has more 
options since introspection can infer a lot from the model. Regular Serializer 
requires more to be done by the developer because it does not assumes much.

> 
> Examples of what I would want:
> 
> There is a table foo with a uuid as the primary key, and another table 
> fooextension with a foreign key pointing to foo.uuid. I was able to hack 
> around that by adding an id field in fooextension, but that's about the limit 
> of the modifications I can make to the database.
> 
> There are many-to-many mappings handled with a map table: classical example 
> is student and teacher; each has a .uuid field, and there is a map table 
> defined as:
> 
> CREATE TABLE student_teacher_map( 
>   student_uuid UUID REFERENCES student(uuid),
>   teacher_uuid UUID REFERENCES teacher(uuid),
>   UNIQUE(student_uuid, teacher_uuid)
> );
> 
> how do I get my models to use this?

That’s a long standing issue with Django. A couple of years (Django < 1.4) ago 
I was able to get it working with some hacks. Would probably use explicit SQL 
nowadays.
> I also need to create models where the various fields come from different 
> tables, but they should be viewed and changed all together. 
That’s were a you should drop ModelSerializer and deal with the mapping 
yourself because there will be a lot of specific logic to be added.

> Are all these things doable in DRF? They are definitely Turing-computable :)

You may want to read how to create a DRF API without models at 
https://medium.com/django-rest-framework/django-rest-framework-viewset-when-you-don-t-have-a-model-335a0490ba6f

> I can't be the first person who ever had this problem, but search engines are 
> not being very helpful here. 
> 
> 
> Thanks,
> 
> /ji
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: RequestsClient headers AttributeError

[Xavier Ordoquy]

Hi,

I was not sure it was in the documentation but it is already:
For drf: http://www.django-rest-framework.org/api-guide/testing/#api-test-cases
For Django: 
https://docs.djangoproject.com/en/2.0/topics/testing/tools/#customizing-the-test-client

Regards,
Xavier.

> Le 23 janv. 2018 à 05:54, Leo T  a écrit :
> 
> Thanks Xavier.
> 
> For anyone who might run into a similar problem with the same setup: I got it 
> working by overriding the request client in the testcase's setup method.
> 
> Is there a reason to use unittest testcase instead of Django testcase? If 
> not, would it make sense to add this caveat in the doc?
> 
> On Monday, January 22, 2018 at 4:53:38 PM UTC-5, Xavier Ordoquy wrote:
> No, you are not. See 
> https://github.com/django/django/blob/master/django/test/testcases.py#L221 
> <https://github.com/django/django/blob/master/django/test/testcases.py#L221>
> 
>> Le 22 janv. 2018 à 22:47, Leo T gmail.com <http://gmail.com/>> 
>> a écrit :
>> 
>> Hi Xavier, I am using DRF's RequestsClient, here is the full code:
>> 
>> from django.test import TestCase
>> from dummy.models import Dummy
>> from rest_framework.test import RequestsClient
>> from requests import Session
>> from user.models import User
>> 
>> class DummyTestCase(TestCase):
>>  
>>  client = RequestsClient()
>>  url = '/dummies/'
>>  headers = {'content-type': 'application/json'}
>>  token = ''
>>  headers = {}
>> 
>>  def setUp(self):
>>  Dummy.objects.create(name='this is a dummy test')
>>  User.objects.create_user('username', 'email', 'Password1234')
>>  result = self.client.post('/api-token-auth/', 
>> data={'username':'username','password':'Password1234'})
>>  self.token = result.data['token']
>>  self.headers['Authorization'] = 'JWT ' + self.token
>> 
>>  def test_can_GET_dummies(self):
>>  self.client.headers.update({'Authorization': 'JWT ' + 
>> self.token})
>>  #print(self.headers)
>>  response = self.client.get(self.url, headers=self.headers)
>>  self.assertEqual(response.status_code, 200)
>>  self.assertEqual(len(response.data), 1)
>> 
>> 
>> As you can see I am setting up a simple Django/DRF/JWT architecture and 
>> testing GET on a dummy model. Everything work fine using Postman, curl, 
>> etc.. But when I use this code and
>> 
>> python manage.py test
>> 
>> I get the above AttributeError on the headers of my RequestsClient object. 
>> If I don't include the faulty line, I get the expected HTTP 401 Unauthorized 
>> as I am not sending the JWT token (I removed Basic and Session 
>> authentication in the settings).
>> 
>> Any idea of what might cause the problem?
>> 
>> Thanks
>> 
>> 
>> 
>> On Monday, January 22, 2018 at 4:34:43 PM UTC-5, Xavier Ordoquy wrote:
>> Hi,
>> 
>> Your code sample works fine on my installation.
>> Ensure you do use the DRF’s RequestsClient and not Django’s.
>> 
>> Regards,
>> Xavier,
>> Linovia.
>> 
>>> Le 22 janv. 2018 à 22:29, Leo T > a écrit :
>>> 
>>> The following code produces the following error. Have I missed something? I 
>>> followed the attached doc.
>>> 
>>> Code:
>>> client = RequestsClient()
>>> client.headers.update({'x-test': 'true'})
>>> 
>>> Error:
>>> AttributeError: 'Client' object has no attribute 'headers'
>>> 
>>> Doc:
>>> http://www.django-rest-framework.org/api-guide/testing/#headers-authentication
>>>  
>>> <http://www.django-rest-framework.org/api-guide/testing/#headers-authentication>
>>> 
>>> 
>>> Thanks for the help
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Django REST framework" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to django-rest-framework+unsubscr...@googlegroups.com <>.
>>> For more options, visit https://groups.google.com/d/optout 
>>> <https://groups.google.com/d/optout>.
>> 
>> 
>> -- 
>> You received this message because you a

Re: RequestsClient headers AttributeError

[Xavier Ordoquy]

No, you are not. See 
https://github.com/django/django/blob/master/django/test/testcases.py#L221

> Le 22 janv. 2018 à 22:47, Leo T  a écrit :
> 
> Hi Xavier, I am using DRF's RequestsClient, here is the full code:
> 
> from django.test import TestCase
> from dummy.models import Dummy
> from rest_framework.test import RequestsClient
> from requests import Session
> from user.models import User
> 
> class DummyTestCase(TestCase):
> 
>   client = RequestsClient()
>   url = '/dummies/'
>   headers = {'content-type': 'application/json'}
>   token = ''
>   headers = {}
> 
>   def setUp(self):
>   Dummy.objects.create(name='this is a dummy test')
>   User.objects.create_user('username', 'email', 'Password1234')
>   result = self.client.post('/api-token-auth/', 
> data={'username':'username','password':'Password1234'})
>   self.token = result.data['token']
>   self.headers['Authorization'] = 'JWT ' + self.token
> 
>   def test_can_GET_dummies(self):
>   self.client.headers.update({'Authorization': 'JWT ' + 
> self.token})
>   #print(self.headers)
>   response = self.client.get(self.url, headers=self.headers)
>   self.assertEqual(response.status_code, 200)
>   self.assertEqual(len(response.data), 1)
> 
> 
> As you can see I am setting up a simple Django/DRF/JWT architecture and 
> testing GET on a dummy model. Everything work fine using Postman, curl, etc.. 
> But when I use this code and
> 
> python manage.py test
> 
> I get the above AttributeError on the headers of my RequestsClient object. If 
> I don't include the faulty line, I get the expected HTTP 401 Unauthorized as 
> I am not sending the JWT token (I removed Basic and Session authentication in 
> the settings).
> 
> Any idea of what might cause the problem?
> 
> Thanks
> 
> 
> 
> On Monday, January 22, 2018 at 4:34:43 PM UTC-5, Xavier Ordoquy wrote:
> Hi,
> 
> Your code sample works fine on my installation.
> Ensure you do use the DRF’s RequestsClient and not Django’s.
> 
> Regards,
> Xavier,
> Linovia.
> 
>> Le 22 janv. 2018 à 22:29, Leo T > a écrit :
>> 
>> The following code produces the following error. Have I missed something? I 
>> followed the attached doc.
>> 
>> Code:
>> client = RequestsClient()
>> client.headers.update({'x-test': 'true'})
>> 
>> Error:
>> AttributeError: 'Client' object has no attribute 'headers'
>> 
>> Doc:
>> http://www.django-rest-framework.org/api-guide/testing/#headers-authentication
>>  
>> <http://www.django-rest-framework.org/api-guide/testing/#headers-authentication>
>> 
>> 
>> Thanks for the help
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django REST framework" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-rest-framework+unsubscr...@googlegroups.com <>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: RequestsClient headers AttributeError

[Xavier Ordoquy]

Hi,

Your code sample works fine on my installation.
Ensure you do use the DRF’s RequestsClient and not Django’s.

Regards,
Xavier,
Linovia.

> Le 22 janv. 2018 à 22:29, Leo T  a écrit :
> 
> The following code produces the following error. Have I missed something? I 
> followed the attached doc.
> 
> Code:
> client = RequestsClient()
> client.headers.update({'x-test': 'true'})
> 
> Error:
> AttributeError: 'Client' object has no attribute 'headers'
> 
> Doc:
> http://www.django-rest-framework.org/api-guide/testing/#headers-authentication
>  
> 
> 
> 
> Thanks for the help
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: Why was auth re-invented? What was missing in django?

[Xavier Ordoquy]

Le vendredi 19 janvier 2018 09:44:52 UTC+1, Thomas Güttler a écrit :
>
> Why was auth re-invented in Django-Rest-Framework? 
>
What was missing in django?
>

I don't know the initial reasons but from my experience, Django has a 
couple of non obvious implicit constraints on the authentication / 
permission that are fine for websites but some APIs require more 
flexibility.
To name a few:
- No clear separation of concerns between authentication and permissions.
- It's not supposed to have different authentication schemes across views.
- Permissions are checked out of the context of the request.
- Permissions are linked to a model, not to a representation (the R of 
ReST).

My problem: We have some APIs which use DRF and some do not use DRF.
>
> Everything works. But the design is ugly since we use different solutions 
> for the same goal.
> This makes our software more complicated and developers waste time.
>

I'm not sure I get your point here.
DRF is loosely coupled. You are free not to use DRF authentication / 
permission and fall back on Django's.
 

> I guess there were valid reasons why this was done. 
>
> Why not improve django, this way everybody (yes, there are people which do 
> not use DRF) could benefit.
>

That would indeed be nice to start bridging that part with Django.
Unless this is a priority for someone it'll likely remain in its current 
state.

Xavier.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can I use DRF 2.4.x with Django 1.11?

[Xavier Ordoquy]

Hi,

It’s unlikely that 2.4 supports Django 1.11 out of the box. Either you’ll have 
to upgrade to a more recent Django REST framework or you’ll have to port DRF 
2.4.x

Regards,
Xavier.

> Le 15 janv. 2018 à 17:23, wolfg  a écrit :
> 
> Hi, I have a project using Django 1.6.x and DRF 2.4.3. Can I upgrade the 
> Django to the 1.11 LTS? The reason is not using DRF 3.x is the project is big 
> and using heavy customization on the top of DRF 2.4.x.
> 
> Regards
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DRF Tutorial Object Level Permissions

[Xavier Ordoquy]

Hi

You should rename « permissions_classes » into « permission_classes »  (note it 
is one letter shorter).

Regads,
Xavier,
Linovia.

> Le 10 janv. 2018 à 07:48, Craig Wilson  a écrit :
> 
> I'm working through the DRF tutorial and everything has been working fine up 
> until topic Object Level Permission. I have modified my project according to 
> the tutorial but I'm still able to delete and edit records related to other 
> users.
> 
> I created permissions.py file:
> 
> from rest_framework import permissions
> 
> 
> class IsOwnerOrReadOnly(permissions.BasePermission):
> """
> Custom permission to only allow owners of an object to edit it.
> """
> def has_object_permission(self, request, view, obj):
> # Read permissions are allowed to any request,
> # so we'll always allow GET, HEAD or OPTIONS requests.
> if request.method in permissions.SAFE_METHODS:
> return True
> 
> # Write permissions are only allowed to the owner of the snippet.
> return obj.owner == request.user
> 
> and modified SnippetDetail view:
> 
> 
> class SnippetDetail(generics.RetrieveUpdateDestroyAPIView):
> """
> Retrieve update or delete a code snippet
> """
> permissions_classes = (permissions.IsAuthenticatedOrReadOnly, 
> IsOwnerOrReadOnly,)
> queryset = Snippet.objects.all()
> serializer_class = SnippetSerializer
> 
> Where am I going wrong?
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: Error in documentation?

[Xavier Ordoquy]

Hi,

Indeed, nice catch.
This was fixed in https://github.com/encode/django-rest-framework/pull/5713 but 
hasn’t been deployed yet (will be for the next release).

Regards,
Xavier.

> Le 1 janv. 2018 à 22:36, Victor M. Mendiola Lau  a écrit :
> 
> Hello everybody.
> 
> I'm new to the Django and Django Rest Framework Ecosystem. I was reading the 
> docs and I think I found an error.
> 
> Under the section 'Adding login to the Browsable API' of 
> http://www.django-rest-framework.org/tutorial/4-authentication-and-permissions/,
>  there seems to be an error in the documentation. The line for including 
> login/logout views for the Browsable API is missing a ')'
> 
> The documentation reads
> . url(r'^api-auth/', include('rest_framework.urls'),
> 
> I think it should be
> . url(r'^api-auth/', include('rest_framework.urls')),
> 
> Best Regards.
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: Django Version 2.0 DRF Support Timeline

[Xavier Ordoquy]

Actually it’s fixed on the repository but documentation will be updated on the 
next release.
As it was already working we aren’t specifically in urge to make a new release.

Regards,
Xavier.

> Le 9 déc. 2017 à 22:57, Joe C  a écrit :
> 
> Hi Xavier,
> 
> Oh, maybe I'll upgrade back to Django 2.0 and try and solve those issues 
> then. The DRF Docs say Django 2.0 is still in alpha.
> 
> Joe
> 
> On Saturday, December 9, 2017 at 1:55:40 PM UTC-8, Xavier Ordoquy wrote:
> Hi joe,
> 
> Latest DRF version should already be compatible.
> There may be some regressions here and there that tests didn’t catch, but so 
> are some bugs with 1.11 too.
> 
> Regards,
> Xavier.
> 
>> Le 9 déc. 2017 à 22:53, Joe C gmail.com <http://gmail.com/>> a 
>> écrit :
>> 
>> Hey,
>> 
>> I'm just setting up a new Django project and I ran into issues with DRF 
>> support so I've decided to start the project on Django 1.11 and upgrade once 
>> the DRF supports Django 2.0. I was wondering if there was any timeline or 
>> expected completion date for DRF fully supporting Django 2.0?
>> 
>> Cheers,
>> 
>> Joe
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django REST framework" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-rest-framework+unsubscr...@googlegroups.com <>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: Django Version 2.0 DRF Support Timeline

[Xavier Ordoquy]

Hi joe,

Latest DRF version should already be compatible.
There may be some regressions here and there that tests didn’t catch, but so 
are some bugs with 1.11 too.

Regards,
Xavier.

> Le 9 déc. 2017 à 22:53, Joe C  a écrit :
> 
> Hey,
> 
> I'm just setting up a new Django project and I ran into issues with DRF 
> support so I've decided to start the project on Django 1.11 and upgrade once 
> the DRF supports Django 2.0. I was wondering if there was any timeline or 
> expected completion date for DRF fully supporting Django 2.0?
> 
> Cheers,
> 
> Joe
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: method GET not allowed

[Xavier Ordoquy]

Hi,

This url:
> url(r'^dashboards', views.DashboardViewCreate.as_view()),
catches all over the others because it doesn’t contains a termination clause.

Regards,
Xavier.


> Le 5 déc. 2017 à 20:15, Angel Omar Rojas Pacheco  a 
> écrit :
> 
> hi everyone
> 
> I have a problem with allow method GET in my project, I find out problem but 
> nothing working.
> 
> this is my urls.py file
> from django.conf.urls import url
> from apicolonybit.dashboard_clbt import views
> 
> 
> urlpatterns = [
> # dashboard
> url(r'^dashboards/$', views.DashboardViewList.as_view()),
> url(r'^dashboards', views.DashboardViewCreate.as_view()),
> url(r'^dashboards/(?P[^/]+)', views.DashboardViewDetail.as_view(), 
> name='dashboard-detail'),
> url(r'^dashboards/(?P\d+)/update', 
> views.DashboardViewUpdate.as_view()),
> 
> ]
> 
> this is my views.py
> 
> class DashboardViewDetail(DetailView): # I try with APIView, and nothing 
> working
> queryset = Dashboard.objects.all()
> serializer_class = DashboardSerializer
> # permission_classes = (permissions.AllowAny,)
> # model = Dashboard
> # get_object and get recover detail from user
> def get(self, request, pk, format=None):
> dashboard_id = self.get_object(pk)
> serializer = DashboardSerializer(dashboard_id, many=True)
> return JsonResponse(serializer.data, safe=False)
> 
> def get_object(self, pk):
> try:
> user = User.objects.get(pk=pk)
> return Dashboard.objects.filter(user_id=user.id)
> except Dashboard.DoesNotExist:
> raise Http404
> 
> my file serializers.py
> 
> from django.http import JsonResponse
> from rest_framework import serializers
> from apicolonybit.dashboard_clbt.models import Dashboard
> 
> 
> dashboard_fields = ('id', 'component', 'column', 'position', 'user')
> 
> 
> class DashboardSerializer(serializers.ModelSerializer):
> class Meta:
> model = Dashboard
> fields = dashboard_fields
> 
> 
> I try everything, but nothing working, the messages in my postman is
> {"detail":"Method \"GET\" not allowed."}
> 
> 
> the url is
> http://127.0.0.1:8000/api/v1/dashboards/2
> 
> I try with
> 
> http://127.0.0.1:8000/api/v1/dashboards/2/
> 
> and not working too
> 
> and sametime not working method put and patch, just working method POST
> 
> in my postman headers sed
> Allow →POST, OPTIONS
> Content-Length →40
> Content-Type →application/json
> Date →Tue, 05 Dec 2017 18:59:33 GMT
> Server →WSGIServer/0.2 CPython/3.5.3
> Vary →Accept
> X-Frame-Options →SAMEORIGIN
> 
> and don't know why not allow GET, PUT AND PATCH.
> 
> I see documentation, and I follow the instructions and not working
> 
> please help me.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: REST framework Official Tutorial 6 bug

[Xavier Ordoquy]

Hi,

The tutorial has no mention of renderer_class but has renderer_classes (note 
the extra ES at the end).

Regards,
Xavier.

> Le 16 nov. 2017 à 14:17, YUN TANG  a écrit :
> 
> I've been following the official tutorial until 6-viewsets-and-routers/ 
> 
> 
> After I changed the urls.py to
> 
> router = DefaultRouter()
> router.register(r'snippets', views.SnippetViewSet)
> router.register(r'users', views.UserViewSet)
> 
> # The API URLs are now determined automatically by the router
> # Additionally, we include the login URLs for the browsable API.
> urlpatterns = [
> url(r'^', include(router.urls)),
> ]
> 
> I got an error: 
> TypeError: SnippetViewSet() received an invalid keyword 'renderer_class'
> 
> 
> Please help. 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why does ModelSerializer have no way to delete the instance?

[Xavier Ordoquy]

Deletion usually doesn’t change model’s field and doesn’t require data from the 
client.
Therefore there’s no real reason a serializer is required, in particular since 
the requisites are on the instance.
Overriding `perform_delete` is definitively what I would do and return a 400 
with a error message.

Regards,
Xavier Ordoquy,
Linovia.

> Le 14 sept. 2017 à 08:00, Vignesh  a écrit :
> 
> I noticed that list, retrieve and update all go through the serializer to 
> perform the actions but destroy does not. My guess is because in these cases 
> a response of the object(s) is required. What I really want to do is perform 
> some validations before deleting an object. 
> 
> I found this Stackoverflow post which touches the subject but the answers 
> felt like a workarounds to me.
> 
> https://stackoverflow.com/questions/21382620/django-rest-framework-validate-before-a-delete
> 
> Currently I have 2 ways to do that,
> Validate in pre_delete() as suggested in SO.
> I feel pre_delete() is already too late to make a decision to delete or not.
> Even though this works for now, I feel signals were not built for this 
> purpose based on the following definition from Django docs. 
> Validation in perform_delete() in the View.
> Again doesn't feel rite considering Serializers have a very nice way to 
> validate objects.
> Django includes a “signal dispatcher” which helps allow decoupled 
> applications get notified when actions occur elsewhere in the framework. In a 
> nutshell, signals allow certain senders to notify a set of receivers that 
> some action has taken place. They’re especially useful when many pieces of 
> code may be interested in the same events.
> 
> 
> So I was curious why delete is missing in ModelSerializers? Are there any 
> reasons that this is not being done? If so, then apart from the above ways to 
> validate objects before deleting them are there other approaches I can try? 
> 
> 
> Thanks,
> Vignesh
> 
> P.S: I just started using restframework and I love it so far! 😁
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Serializer Field Meta validators

[Xavier Ordoquy]

Hi,

DRF fields adds the validators during the init rather than setting them on Meta.
That help with heritage.

You can see how this works at 
https://github.com/encode/django-rest-framework/blob/master/rest_framework/fields.py#L799-L802

Hope this helps,
Regards,
Xavier Ordoquy,
Linovia.

> Le 11 sept. 2017 à 12:54, phi...@futrli.com a écrit :
> 
> Hi all,
> 
> I'm trying to add a list of validators to a subclass of 
> rest_framework.fields.Field.
> I would prefer to add the validators to the field declaration, rather than 
> every place it is used.
> 
> Ideally, I would like to be able to declare the Field similarly a Serializer, 
> e.g:
> 
> class MyField(rest_framework.fields.Field):
> class Meta:
> validators = (
> my_validation_function,
> )
> 
> However, it looks like the Meta class is only used in subclasses of 
> Serializer, and not in subclasses of Field.
> 
> 
> Adding the validators during __init__ is pretty ugly:
> 
> class MyField(rest_framework.fields.Field):
> def __init__(self, read_only=False, write_only=False, required=None, 
> default=empty, initial=empty, source=None,
>  label=None, help_text=None, style=None, error_messages=None, 
> validators=None, **kwargs):
> if validators is None:
> validators = []
> else:
> validators = list(validators)
> default_validators = (
> my_validator,
> )
> validators.extend(default_validators)
> super().__init__(read_only, write_only, required, default, initial, 
> source, label, help_text, style,
>  error_messages, validators, **kwargs)
> 
> 
> Is there a better way to add a list of validators to a field inside the 
> declaration of the field?
> 
> Thanks in advance for any help,
> Phil Woods
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Regular serializer in browsable api

[Xavier Ordoquy]

Hi,

The question is a bit too opened to be answered.
https://medium.com/django-rest-framework/django-rest-framework-viewset-when-you-don-t-have-a-model-335a0490ba6f
 
<https://medium.com/django-rest-framework/django-rest-framework-viewset-when-you-don-t-have-a-model-335a0490ba6f>
 may help you to get something working.

Regards,
Xavier Ordoquy,
Linovia.

> Le 27 août 2017 à 17:54, Ivlev Denis  a écrit :
> 
> 
> Hi.
> I have ModelSerializer with field of regular Serializer, them not showed in 
> browsable api. What am I doing wrong?
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is it possible to set permission_classes for OR relation

[Xavier Ordoquy]

Hi,

You’ll need to implement an intermediate permission classe that would perform 
the OR and delegate the permission check to the subclasses.

Regards,
Xavier Ordoquy,
Linovia.

> Le 19 juil. 2017 à 19:29, William Huang  a écrit :
> 
> Hi All,
> 
> Is it possible to set permission_classes for OR relation ?
> for example I want to allow a logged in user or an admin user to this view, 
> so I set:
> 
> permission_classes = (IsAuthenticated, IsAdminUser)
> 
> Is this correct?
> 
> Thank you!
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: rest_framework.authtoken is missing in version 3.6.3

[Xavier Ordoquy]

Hi,

As far as I can tell, it is available and running well.
What makes you think it doesn’t ?

Regards,
Xavier Ordoquy,
Linovia.

> Le 27 juin 2017 à 19:28, Roberto Santos  a écrit :
> 
> Dear all
> 
> I've just upgraded from version 3.6.2 to 3.6.3 and realised that authtoken is 
> not available. Is it correct or a mistake?
> 
> Best wishes
> Roberto
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stop creating Duplicate values on post request

[Xavier Ordoquy]

Hi,

You didn't provide the HumanSerializer so there's little we can do.

Regards,
Xavier Ordoquy,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Custom field implementation of BooleanField not efective when serialized object is retrieved

[Xavier Ordoquy]

Hi,

We can’t provide any meaningful answer here as you don’t provide any hint about 
how you wrote the serializer.

Regards,
Xavier Ordoquy,
Linovia.

> Le 20 juin 2017 à 08:25, Priyanka Thakur  a écrit :
> 
> Hi,
> 
> I have defined a custom field instead of BooleanField in my project.
> 
> Custom field is defined in model with  no default value , example:
> 
> class MyModel(models.Model):
>is_folder = HibernateBooleanField()
> 
> 
> where HibernateBooleanField is the custom calss for overriding "to_python", 
> "from_db_value" methods.
> 
> When making a POST request, the object is getting saved by invoking the 
> proper methods from Custom field implementation. 
> 
> But when getting the serialized object , "is_folder" value is returned as 
> "None" .
> 
> Though I understand that default value for BooleanField is "None", does that 
> mean with DRF 3.6 we have to mandatorily define default values for Boolean 
> Field, if i want to use "False" and "True" ?
> 
> Also , why isn't any method invoked from Custom field implementation?
> 
> This is custom field implementation:
> 
> from django.db import models
> 
> # #
> # This is for dealing with BIT (boolean) type of Hibernate
> # #
> class HibernateBooleanField(models.BooleanField):
> def from_db_value(self, value, expression, connection, context):
> return self.to_python(value)
> 
> def get_internal_type(self):
> return "HibernateBooleanField"
> 
> def db_type(self, connection):
> return 'bit(1)'
> 
> def to_python(self, value):
> if value in (True, False):
> return value
> if value in ('t', 'True', 'true', '1', '\x01'): return True
> if value in ('f', 'False', 'false', '0', '\x00', None): return False
> 
> def get_db_prep_value(self, value, connection, prepared=False):
> return 0x01 if value else 0x00
> 
> def get_db_prep_save(self, value, connection):
> return 0x01 if value else 0x00
> 
> Regards,
> Priyanka
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Error in tutorial (calling serializer.data)?

[Xavier Ordoquy]

Hi,

serializer.data should only be used for serialization.
If you try to access it during deserialization, you’ll get a warning from the 
framework:

serializer = SnippetSerializer(snippet)
serializer.data
or

serializer = SnippetSerializer(data=data)
serializer.is_valid()
serializer.validated_data
serializer.save()
But in the latter case, you can’t call serializer.data (doesn’t make sense 
either as you provided the data in the first place).

Hopes this helps,
Xavier Ordoquy,
Linovia.


> Le 19 juin 2017 à 16:05, mrlemon  a écrit :
> 
> Hi - just come to DRF; exploring for an upcoming project.
> 
> Is there an oversight in the tutorial 
> (http://www.django-rest-framework.org/tutorial/1-serialization/) or am I 
> doing something wrong?
> 
> The framework guards against calling serializer.data,but states that you do 
> so in the tutorial.
> 
> I see the issue <https://github.com/encode/django-rest-framework/issues/2490> 
> on this, but it's I'm still getting the error when restarting the shell and 
> following the tutorial without calling serializer.data.
> 
> Any advice welcome.
> 
> 
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: get_identity method of BaseSerializer removed in DRF 3.x version. But no documentation

[Xavier Ordoquy]

Hi,

mapping between data and instances is performed when instantiating the 
serializer.
Depending on your use case, it'll be get_object and/or your own code that 
would substitute to it.

Regards,
Xavier Ordoquy,
Linovia.

Le mercredi 14 juin 2017 18:44:09 UTC+2, Priyanka Thakur a écrit :
>
> Hi,
>
> We have overridden the "get_identity" method of BaseSerializer class in 
> DRF 2.3 version. But in DRF 3.6.2 version this method is no longer 
> supported.
>
> I tried looking for documentation, but couldn't found any.
>
> Please guide and explain how can i overide this implementation using DRF 
> 3.6.
>
> Regards,
> Priyanka
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: pre_save and post_save replacement methods in DRF 3.6.2

[Xavier Ordoquy]

Hi,

it means you can perform the pre save before calling super’s 
perform_create/update and then call the post_save from you override 
perform_create/update.

Regards,
Xavier Ordoquy,
Linovia.

> Le 13 juin 2017 à 11:09, Priyanka Thakur  a écrit :
> 
> Hi,
> 
> Though i have gone through DRF 3.6 docs, but just to be clear from concept  
> p.o.v.
> 
> I understand that pre_save , post_save methods have been removed from DRF 3.x 
> version onwards and perform_create and perform_update methods are their 
> replacement .
> 
> Does it mean that post_save method has to be replaced with "perform_update" 
> method while pre_save is replaced with "perform_create" method?
> 
> 
> Regards,
> Priyanka
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PrimaryKeyRelatedField doesn't validate null value even if allow_null=True

[Xavier Ordoquy]

At this point I’m still convinced it’s an issue on client side either by 
sending proper declared JSON but containing the null string instead of the null 
value itself or because it’s sent as x-www-form-urlencoded (easy to fall into 
that issue).
If you think it’s a DRF bug, you should start writing a test case to 
demonstrate the issue.

Regards,
Xavier Ordoquy,
Linovia.

> Le 30 mai 2017 à 13:33, Priyanka Thakur  a écrit :
> 
> Hi Xavier,
> 
> Sorry, I misunderstood the earlier statement "JSON payload.".
> 
> Actually, you are right , the data which is fed to serializer for validating 
> is in the form of JSON , since data is obtained at the internal API level 
> using request.data (which generates unicode data).
> 
> But to me, it seems like a bug in DRF, reason being if we don't override the 
> implementation of "create" or "update" method, serializer validation will 
> fail everytime, if we have "null" values in Database .
> 
> Please correct me if I'm wrong in my understanding. 
> 
> Regards,
> Priyanka
> 
> On Tuesday, 30 May 2017 12:24:36 UTC+5:30, Priyanka Thakur wrote:
> I am using Django rest 3.6.2 version .
> 
> The model class is having a ForeignKey relationship as :
> 
> class Deliverable(model.Model):
> architectureattribute = models.ForeignKey(Architectureattribute, 
> blank=True, null=True)
> 
> 
> 
> class DeliverableSerializer(serializers.ModelSerializer):
> class Meta:
>  model = Deliverable
>  fields = tuple([getattr(x, 'name') for x in 
> Deliverable._meta.fields])
> 
> 
> In Django Rest , the serializer object is decoded as for the foreign key as:
> 
> architectureattribute = PrimaryKeyRelatedField(allow_null=True, 
> queryset=Architectureattribute.objects.all(), required=False)
> 
> 
> With a put request i am updating only some fields and since I'm doing 
> migration, Database contains null value for the architectureattribute.
> 
> But with "null" value , serializer validation is failing. 
> 
> On debugging I found that the PrimaryKeyRelatedField is not handling the 
> "null" value, even though allow_null property is set. 
> 
> Please explain or guide, as to what I'm doing wrong here . 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PrimaryKeyRelatedField doesn't validate null value even if allow_null=True

[Xavier Ordoquy]

I highly suspect you’re sending JSON payload with a Form like content type.

JSON’s null is not a unicode.

Regards,
Xavier Ordoquy,
Linovia.

> Le 30 mai 2017 à 10:31, Priyanka Thakur  a écrit :
> 
> The request is a PUT request , in a test case and the response from the 
> serializer API is : 
> 
> --copy--
> {'architectureattribute': [u'Incorrect type. Expected pk value, received 
> unicode.']
> --copy--
> 
> This is the error from serializer, which is serializer ouput and not custom 
> print output.
> 
> Also, the below instance is part of serializer instance ouput. 
> 
> --copy--
> architectureattribute = PrimaryKeyRelatedField(allow_null=True, 
> queryset=Architectureattribute.objects.all(), required=False)
> --copy--
> 
> Well anyhow, though I have reduced the problem to more granular level.
> 
> QueryDict output contains output in unicode format and hence the comparison 
> while "validate_empty_values" with "None" object is failing.
> 
> I'm still struggling with 3.6.2 version and haven't tried with 3.6.3 version.
> 
> On Tuesday, 30 May 2017 12:24:36 UTC+5:30, Priyanka Thakur wrote:
> I am using Django rest 3.6.2 version .
> 
> The model class is having a ForeignKey relationship as :
> 
> class Deliverable(model.Model):
> architectureattribute = models.ForeignKey(Architectureattribute, 
> blank=True, null=True)
> 
> 
> 
> class DeliverableSerializer(serializers.ModelSerializer):
> class Meta:
>  model = Deliverable
>  fields = tuple([getattr(x, 'name') for x in 
> Deliverable._meta.fields])
> 
> 
> In Django Rest , the serializer object is decoded as for the foreign key as:
> 
> architectureattribute = PrimaryKeyRelatedField(allow_null=True, 
> queryset=Architectureattribute.objects.all(), required=False)
> 
> 
> With a put request i am updating only some fields and since I'm doing 
> migration, Database contains null value for the architectureattribute.
> 
> But with "null" value , serializer validation is failing. 
> 
> On debugging I found that the PrimaryKeyRelatedField is not handling the 
> "null" value, even though allow_null property is set. 
> 
> Please explain or guide, as to what I'm doing wrong here . 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PrimaryKeyRelatedField doesn't validate null value even if allow_null=True

[Xavier Ordoquy]

> Le 30 mai 2017 à 08:54, Priyanka Thakur  a écrit :
> 
> I am using Django rest 3.6.2 version .
> 
> The model class is having a ForeignKey relationship as :
> 
> class Deliverable(model.Model):
> architectureattribute = models.ForeignKey(Architectureattribute, 
> blank=True, null=True)
> 
> 
> 
> class DeliverableSerializer(serializers.ModelSerializer):
> class Meta:
>  model = Deliverable
>  fields = tuple([getattr(x, 'name') for x in 
> Deliverable._meta.fields])
> 
> 
> In Django Rest , the serializer object is decoded as for the foreign key as:
> 
> architectureattribute = PrimaryKeyRelatedField(allow_null=True, 
> queryset=Architectureattribute.objects.all(), required=False)
> 
> 
> With a put request i am updating only some fields and since I'm doing 
> migration, Database contains null value for the architectureattribute.
> 
> But with "null" value , serializer validation is failing. 
> 
> On debugging I found that the PrimaryKeyRelatedField is not handling the 
> "null" value, even though allow_null property is set. 
> 
> Please explain or guide, as to what I'm doing wrong here . 

Before going further, a few points need to be more clear.
Can you provide the request’s payload you’re sending ?
What’s the exact response message or the traceback ?
Can you print a serializer’s (not your code, but an actual serializer’s 
instance) so we can check what constraints it has ?
Did you try with the latest Django REST framework version ?

Regards,
Xavier Ordoquy,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GitHub Process]: New Project for API Docs?

[Xavier Ordoquy]

> Le 19 mai 2017 à 10:42, Carlton Gibson  a écrit :
> 
> Hiya, 
> 
> I'm trying to get a grip on the tickets relating to the generated API 
> documentation. My issue is GitHub's tracker doesn't offer great ways of 
> filtering to just the relevant tickets. 

Thanks for dealing with it :)

> In the past we've tried using Labels to group tickets by functionality, but 
> we have those for Process. 
> 
> So, any objection to creating a Project for this functionality and adding 
> tickets to that? 

Looks good to me in particular given the increasing number of issues about it.

> Cheers, 
> C.

Regards,
Xavier O.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django rest framework - nested serializer - retrieve valid records of nested serializer and error for invalid

[Xavier Ordoquy]

Hi,

You will need to loop on the items and use a serializer on each of them.

Regards,
Xavier Ordoquy,
Linovia.

> Le 14 mai 2017 à 07:19, Gaurav Pant  a écrit :
> 
> 
> 0
> down vote
>  <>favorite
>  
> <http://stackoverflow.com/questions/43960378/django-rest-framework-nested-serializer-retrieve-valid-records-of-nested-ser#>
>   
> I am retrieving multiple client records at a time using 
> "RegistrationSystemSerializer" serialize here.
> 
> class ClientRecordSerializer(serializers.Serializer):
> client_id = serializers.IntegerField()
> date_of_birth = serializers.DateField()
> 
> class RegistrationSystemSerializer(serializers.Serializer):
> count = serializers.IntegerField()
> results = ClientRecordSerializer(many=True)
> If anytime anyone of client records is invalid then it is aborting entire 
> process of extraction. i.e. suppose I have data like
> 
> {
> "count" : 4,
> "results":[
> {
>"client_id":"1234",
>"date_of_birth":"2012-02-06"
> },
> {
>"client_id":"2345",
>"date_of_birth":"2013-02-06"
> },   
> {
>"client_id":"4567",
>"date_of_birth":"2014-02-06"
> },   
> {
>"client_id":"1239",
>"date_of_birth":"06-02-2017"# invalid date format
> },   
>  ]
> }
> where "date_of_birth" of 4th client is in wrong format because a valid date 
> can be only in "-MM-DD" format. If I apply above serialize in this data 
> then it will not give me any data because one of the nested record do not 
> satisfy criteria. What I want is to get all three valid nested records from 
> serialize but error for the fourth one.
> 
> How to achieve the same using Django rest framework.
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Factory pattern for serializers

[Xavier Ordoquy]

Hello,

It doesn’t really make sense to create a factory here.
Django forms requires some overhead to handle the form management part whereas 
DRF’s serializers don’t need that.
You should be able to write your own factory using Python’s type(name, bases, 
dict).

Regards,
Xavier Ordoquy,
Linovia.


> Le 2 mai 2017 à 00:27, Aidan Lister  a écrit :
> 
> Is there a factory pattern for serializers, ala modelform_factory or 
> modelformset_factory?
> 
> I end up doing this type of stuff a lot, e.g. a full serializer, a lite 
> serializer, etc. it'd be cool to do either: BranchListSerializer = 
> serializerfactory(BranchSerializer, fields=('id', 'name'))
> 
> 
> class BranchSerializer(serializers.ModelSerializer):
> property_count = serializers.IntegerField(read_only=True)
> current_business_hours = serializers.SerializerMethodField()
> 
> 
> def get_current_business_hours(self, obj):
> in_bh, bh = obj.get_business_hours_for_date()
> return {
> 'in_bh': in_bh,
> 'hours': bh,
> 'is_set': bool(obj.business_hours),
> }
> 
> 
> included_serializers = {
> 'groups': 'abas.apps.accounts.api.v2.serializers.UserGroupSerializer',
> 'user_set': 'abas.apps.accounts.api.v2.serializers.UserSerializer',
> }
> 
> 
> class Meta:
> model = Branch
> fields = (
> 'id',
> 'name',
> 'code',
> 
> 
> # relationships
> 'groups',
> 'property_count',
> 'user_set',
> 
> 
> # methods
> 'get_absolute_url',
> 'current_business_hours',
> )
> 
> 
> 
> 
> class BranchNameSerializer(BranchSerializer)
> class Meta:
> model = Branch
> fields = (
> 'id',
> 'name',
> )
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How do you implement custom response?

[Xavier Ordoquy]

Hi,

I’m not sure about the requirements around your use case but options are:
- rewrite the mixins.py classes to add your extra data (let’s say it’s only 
JSON that requires it)
- write your own JSONRenderer to add the extra informations and leave other 
renderers as they currently are.

Hopes this helps,
Xavier Ordoquy,
Linovia.

> Le 17 avr. 2017 à 09:52, Yanze Dai  a écrit :
> 
> I found that the DRF's return value could be various upon different 
> occasions. So I want to make sure all my JSON return have "code" "message" or 
> other values nested inside in order to keep consistency of my APIs.
> For example:
> 
> Success
> 
> {"code": 1, "status": "success", "message": "",
> "data": [{"id": 1, "name": "John Doe", "email": "john...@gmail.com"}]}
> 
> Error
> 
> {"code": -1, "status": "error", "message":"Something went wrong","data": [] }
> 
> The return will always have "code" "status" "message" "data" inside whatever 
> the result would become.
> 
> After looked up in Google but couldn't find any work-around over DRF. So I 
> suppose everybody is redefining the APIViews or Mixins (get put post etc. ) 
> to control the response. But I am not very sure if the return should be that 
> widely different without a certain pattern. Or is it cool that DRF's JSON 
> response could be directly adopted as a production case?
> 
> Hope to have some advice from you guys.
> Thanks.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: serializer.is_valid() throws error - "to_internal_value() must be implemented"

[Xavier Ordoquy]

Hi,

Why did you use BaseSerializers ?

Regards,
Xavier Ordoquy,
Linovia.

> Le 14 avr. 2017 à 23:44, Suprita Shankar  a écrit :
> 
> Context: I am having problem accessing fields which are validated by nested 
> serializers.
> I have a very sample model as shown below. 
> For 2 of the fields I have their specific serializers. When I try to access 
> the data it returns all the fields except the one validated by the specific 
> serializers. 
> 
> Models looks like this
> 
> class Sampler(models.Model):
>   sample_name = models.CharField(unique=True, max_length=100)
>   sampling_by = JSONField(max_length=100)
>   extractions = JSONField(max_length=100)
>   max_samples = models.IntegerField(default=100)
> 
> 
> Serializers
> 
> class ExtractionsSerializer(serializers.BaseSerializer):
>table_name = serializers.CharField()
>extraction_type = serializers.ChoiceField(["ABC"])
>dependencies = serializers.ListField(child=RecursiveField(), 
> allow_empty=True, required=False)
> 
> 
> class SamplingBySerializer(serializers.BaseSerializer):
> """
> Validate sampling_by
> """
> def to_internal_value(self, samples):
>   methods = ["ABC"]
>   sampling_not_supported = [sample for sample in samples
>   if sample['by'] not in methods]
>if sampling_not_supported:
>   raise ValidationError("{} not in 
> {}".format(sampling_not_supported, methods))
> 
> class SamplerSerializer(serializers.ModelSerializer):
> extractions = ExtractionsSerializer()
> sampling_by = SamplingBySerializer()
> 
> class Meta:
>   model = Sampler
>   fields = ('sample_name', 'database', 'schema', 'sampling_by', 
> 'extractions', 'max_samples')
> 
> def create(self, validated_data):
>   return Sampler(**validated_data)
> 
> Now I do
> 
> data = {
>   "database": "postgresql://..",
>   "sampling_by":[{
>   "by":"ABC",
>   "value": ["l32=turn_the"]
>   }],
>   "max_samples":3,
>   "extractions" : [{
>   "table_name": "person", 
>   "extraction_type": "ABC"
>   }]
> }
> sampler = SamplerSerializer(data=data)
> sampler.is_valid() #Gives error. It says that `to_internal_value()` needs 
> to be implemented.
> 
> Any help would be appreciated! thanks
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ApiClient and AcceptHeaderVersioning

[Xavier Ordoquy]

Hi,

Unfortunately at the moment, you’ll have to perform the call to json.dumps, 
drop the format and use content-type to set the version.

Regards,
Xavier Ordoquy,
Linovia.

> Le 5 avr. 2017 à 11:09, Tobias Zanke  a écrit :
> 
> I am using the AcceptHeaderVersioning and like to write some tests. At the 
> moment i do it this way:
> 
> 
> 
> .put(url, **{'HTTP_ACCEPT': 'application/json; version=1'})
> 
> 
> 
> But i would like to write the code like this
> 
> 
> 
> .put(url, format='json', version='1')
> 
> 
> 
> Whats the correct way atm? I could not find anything related to testing a 
> AcceptHeaderVersioning API
> 
> 
> 
> Best Regards
> 
> Tobias
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Possible bug: date is not translated by serializer

[Xavier Ordoquy]

Hi,

> Are you saying date translation should only be done on the client ?

I’m saying that’s an option and possibly a better solution.
If one goes in another timezone, one is more likely to change its computer 
timezone than go through every website and change the settings there.

> Unlike in Django, which is happy to translate the date for you ?

That’s inexact as Django doesn’t translate the date for you out of the box. 
Extract from the Django documentation:

"The current time zone is the equivalent of the current locale for 
translations. However, there’s no equivalent of the Accept-Language HTTP header 
that Django could use to determine the user’s time zone automatically. Instead, 
Django provides time zone selection functions. Use them to build the time zone 
selection logic that makes sense for you."

> More code duplication.

Can you elaborate ?

> Is there anything conceptually wrong with an API providing a translated date 
> according to request language ?

Which ones of PT, MT, CT or ET are you going to choose for en-US ?

> Marek

Regards,
Xavier Ordoquy,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Writing to Nested ModelSerializer

[Xavier Ordoquy]

 it be used to access the self.Meta.model manager in the Color 
> serializer, to lookup an existing Color object, and return the instance to 
> the parent. 
Here, you’re fighting on two things at the same time. On one side it’s a nested 
serializer, on the other it’s a custom field. Let’s make things simpler as 
proposed in my previous answer.

> 3) The validation automatically occurs for the nested data, by drilling down 
> into each serializer class, but I found the create method DOES NOT appear to 
> follow the relationship.
> When it comes to saving the validated data, the create() method is called for 
> the serializer associated to the parent Car object.
> To handle the nested create, it seems this all needs to be done from the 
> parent (Car) serializer; using the model manager methods (.get(), .create(), 
> etc), for BOTH the Car and Color objects. 
> Why can't the parent serializer (Car) see that a nested relationship exists, 
> and call the nested create method?
> It seems cleaner to have the child Color.create() handle the lookup for 
> existing or create new (Color.objects.get_or_create), and return the instance.
> Then the parent Car serializer create can finish creating the Car object with 
> the instance returned from the Color serializer.
> This way each serializer locally handles the validation, lookup, and creation.
> If the nested depth is 5, the serializer at level1 would have a really 
> complicated create() method.
Create/update is performed in the root serializer because this allows much more 
complex use cases to be handled by developers.
We tried to make nested serializers automated back in 2.x and it didn’t work. 
There was too many use case to deal with and each fixed bug added another 2 to 
5 edge cases.
One of the key issue is the order in which the nested data has to be created.
For a FK, you need to create the nested element first and then the root one 
with the FK to the nested.
For a reversed FK, it’s the other way round.
For many to many, both should be created before joining them.

Try to figure how to deal with those cases where you have several nesting 
levels mixing the previous cases ?
If you isolate the creation / update the serializer needs to figure the right 
order and that’s extremely complex and fragile.

Another reason is more simple to get.
We says you need to call the nested serializer’s create when create is called 
on the root ?
It may just be an update or just a description of an existing nested instance. 
How could the framework figure it by himself ?

And yes, for nested level above 2, the create/update are complex. One should 
challenge its desire or need to have such use case.

> 4) ModelSerializer is nice for simple models like the example, so why would I 
> want to convert it to a Serializer?
> I have read Tom mention mention many times to re-write the ModelSerializer as 
> a Serializer, but I want to understand the real differences with 
> ModelSerializer vs Serializer.
The thing being that most - if not all - of us have boxed thoughts and it’s 
hard sometime to think out of the box.
ModelSerializer is nice to get started and may go quite far. However, while 
processing the various project requirements we get caught in moving forward 
with a ModelSerializer where it doesn’t make sense. We bend it and try to make 
it fit something it’s not a good fit for. Then we blame the framework for being 
hard to deal with if not worst.
ModelSerializers are Serializers that performs some interaction on a Model.
The issue is resource representations should not be contraints by the storage - 
i.e. the Model.

> Thanks in advance,
> Jason

Hope this will help,
Xavier Ordoquy,
Linovia

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Possible bug: date is not translated by serializer

[Xavier Ordoquy]

Hi,

You got it right.
Please note that an accept language is by no mean a location.
en-US is 4 or 5 timezones (don’t remember and limited internet connection, 
you’ll correct), let alone russian.
Amazingly France spans 11 timezones (iirc, no april fool) so pretty hard for 
fr-FR to set a TZ.

That put apart the default behavior would be to return the timezone 
informations so your client can do the translation by itself.
I remember an API (written with DRF) that was returning the ISO string (so UTC) 
and angular converted it to the local timezone (CET by that time) shift 
appropriately the time.
My bet here, you don’t provide TZ information so your JS client may not perform 
the correct translation.

Regards,
Xavier Ordoquy,
Linovia.

> Le 31 mars 2017 à 19:30, marek.onus...@gmail.com a écrit :
> 
> Hi,
> 
>  I'm learning Django Rest Framework but otherwise I'm quite proficient with 
> Django.
> 
> I have a website which uses translations, the usual stuff: {% trans %}, {% 
> blocktrans %}, but also JavaScriptCatalog for xhr. So far, so good. 
> Everything is translated into one of the website's languages, English and 
> Polish.
> 
> However, I also have asynchronous pagination using rest framework and xhr. 
> The dates returned by my xhr / REST requests are not translated, even with 
> Accept-Language set in request header.
> 
> models.py:
> 
> pub_date = models.DateTimeField(_("Publication date"), auto_now_add=True)
> mod_date = models.DateTimeField(_("Modification date"), auto_now=True)
> 
> in views.py: generics.ListAPIView
> 
> serializers.py: (serializers.ModelSerializer)
> 
> pub_date = serializers.DateTimeField(format='%d %b %Y')
> mod_date = serializers.DateTimeField(format='%d %b %Y')
> 
> request, using the commandline tool httpie:
> 
> http http://10.7.90.5:8000/karty/api/ Accept:application/json 
> Accept-Language:pl
> 
> I've tried setting it to both 'en' end 'pl'. In the user-facing view I get 
> either Polish or English depending on the header, that's how I know the 
> syntax is correct. But in the API views the date is always in english.
> 
> Language code is not specified in settings.py, so it uses default. 
> LocaleMiddleware is enabled and works for the rest of the website. It's a toy 
> / exercise project so most settings are on their default values.
> 
> Am I missing something ? I read the 'internationalization' chapter of the 
> rest framework documentation, and I don't see anything. Actually, the opening 
> paragraph and the choice of examples implies that error messages are the only 
> thing you may want to translate. So it looks like an omission in design to me.
> 
> Cheers,
> Marek Onuszko
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: UniqueTogetherValidator model serializer or model viewset logic for custom "lat-long" django model field with pre-save method

[Xavier Ordoquy]

> Le 24 mars 2017 à 02:00, Mark Mikofski  a écrit :
> 
> Hi Xavier,
> 
> Thanks for your quick reply. I had to rush off and I didn't get to finish the 
> post. Sorry!
> 
> Yes, I can make model objects and save them to the database using w = 
> Weather(latitude=x, longitude=y, header="blah", datatype=3) and w.save().

There are slightly but significant differences between the .save() and 
Weather.objects.create(..)

> The issue only occurs when I test the unique together constraint by posting a 
> duplicate.
> 
> If the serializer looks like this:
> 
> class WeatherSerializer(serializers.ModelSerializer):
> """weather serializer"""
> 
> class Meta:
> model = Weather
> exclude = ('lat_long',)
> 
> then I can post new records fine. But if I try to post a duplicate that's 
> when I get the integrity error, and since the validator is missing from the 
> serializer, the server says 500.

The traceback would help understand what we are speaking about.

> If I remove the line `exclude = ('lat_long')` then the serializer _does_ have 
> the `UniqueTogetherValidator` which I can see in a Django shell as 
> WeatherSerializer().validators
> 
> However, now if I try to post a duplicate, instead of getting 500, I do get 
> 400, good, but the message is not "non_field_errors": ["The fields lat_long, 
> header, datatype must make a unique set."], instead I get "lat_long": ["This 
> field is required."]
> 
> * I realize I should/could use DecimalField for latitude and longitude and 
> that would resolve my problem.
> * I tried using HiddenField but couldn't get it to make the lat_long value 
> without knowing the serializer object a priori
> * SerializerMethodField with get_lat_long(obj) method didn't work either

If you have a unique constraint on those fields, serializer will blow because 
it enforces the check before saving meaning the field isn’t ready.
Exclude the field, remove the constraint and perform the check by yourself.

Regards,
Xavier Ordoquy,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: UniqueTogetherValidator model serializer or model viewset logic for custom "lat-long" django model field with pre-save method

[Xavier Ordoquy]

Hi,

I’m definitively not sure about that too.
Could you try to create a Weather instance as 
Weather.objects.create(latitude=xx, longitude=xx) and see if it works and set 
correctly automatically the latlong value, then it’s likely a DRF issue.
Otherwise, you may want to discuss that on the django user mailing list first.

Regards,
Xavier Ordoquy,
Linovia.

> Le 23 mars 2017 à 23:47, Mark Mikofski  a écrit :
> 
> Hi, I have a Django (1.8.5) model with a custom field that calls pre-save() 
> to evaluate the field from other model fields:
> 
> class LatLongField(models.CharField):
> """
> Custom field class based on :class:`~django.db.models.CharField` that
> creates a string field from the site coordinates.
> """
> def pre_save(self, model_instance, add):
> """
> Create the lat long field the every time the model is saved.
> """
> # save latitude and longitude with 3 decimal places
> value = '%.3f %.3f' % (model_instance.latitude,
>model_instance.longitude)
> setattr(model_instance, self.attname, value)
> return value
> 
> This custom field is used in a model with latitude and longitude to create a 
> string that can be "unique". The custom field is used in a unique together 
> constraint:
> 
> class Weather(models.Model):
> latitude = models.FloatField()
> longitude = models.FloatField()
> header = models.CharField()
> datatype= models.ChoiceField()
> latlong = models.LatLongField()
> 
> If I make a model serializer no matter what I get, lat-long field is 
> required. If I exclude it from the serializer, I get no validators and an 
> integrity error exception (500 server error)
> 
> Is this a django issue or a drf issue?
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is it possible get JSON-Schema from API fitting for jsonschema2pojo.org?

[Xavier Ordoquy]

Hi,

You’ll likely want to alter the way metadata are rendered: 
http://www.django-rest-framework.org/api-guide/metadata/#custom-metadata-classes
 
<http://www.django-rest-framework.org/api-guide/metadata/#custom-metadata-classes>

Regards,
Xavier Ordoquy,
Linovia.

> Le 21 mars 2017 à 13:00, flatwater...@gmail.com a écrit :
> 
> Hello!
> I have a django application with django-rest-framework and Android 
> application.
> I want to generate JSON-Schema from my API fitting for jsonschema2pojo.org.
> It means I want structure with properties like following
> 
> {
>   "type":"object",
>   "properties": {
> "foo": {
>   "type": "string"
> },
> "bar": {
>   "type": "integer"
> },
> "baz": {
>   "type": "boolean"
> }
>   }
> }
> I know about coreapi but it generates another schema.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why is 'write_only_fields' not used?

[Xavier Ordoquy]

My opinion is that read_only_fields feature is already provided by extra_kwargs 
which does much more than just set the read/write flag. That would also help 
provide this feature which is under used by users.

Note that I said "I’m willing to remove it" and did *not* say "it will be 
removed".

Regards,
Xavier Ordoquy,
Linovia.

> Le 17 mars 2017 à 07:43, CocaCola  a écrit :
> 
> Will read_only_fields also disappear? soon?
> 
> 
> Any reason?
> 
> class SomeSerializer(serializer.ModelSerializer):
> class Meta:
> model = SomeModel
> fields = ('somefield1', 'somefield2', 'somefield3')
> extra_kwargs = {
> 'somefield2': {'write_only': True},
> 'somefield3': {'read_only': True}
> }
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why is 'write_only_fields' not used?

[Xavier Ordoquy]

Hi,

We didn’t remove the read_only_fields as it’s pretty common.
However, I would be willing to remove the read_only_fields since the 
extra_kwargs is already there.

Regards,
Xavier Ordoquy,
Linovia.

> Le 17 mars 2017 à 07:01, CocaCola  a écrit :
> 
> in documents..
> 
> The write_only_fields option on ModelSerializer has been moved to 
> PendingDeprecation and replaced with a more generic extra_kwargs
> 
> 
> http://www.django-rest-framework.org/topics/3.0-announcement/#the-extra_kwargs-option
> 
> 
> Why do not you use 'write_only_fields' while using 'read_only_fields'?
> 
> I think it is more intuitive to use the same sentence.('read_only_fields / 
> write_only_fields)
> Why was it abandoned?
> For what reasons?
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem interacting with API using the generated documentation

[Xavier Ordoquy]

Hi,

Logs from the server would really be helpful here.
What does it says ? 500 ? 400 ?
If 500, what’s the traceback ?

Regards,
Xavier Ordoquy,
Linovia.

> Le 16 mars 2017 à 16:51, Antoine Nguyen  a écrit :
> 
> Hi,
> 
> I'm making some tests with the built-in documentation (really nice work btw) 
> and it looks like the interactive mode does not work completly. I'm playing 
> with a list operation, I can see the request is sent and that it returns data 
> but it is not displayed in the window, I just get an "undefined" message. A 
> screenshot is attached.
> 
> What am I doing wrong?
> 
> Thank you,
> Antoine Nguyen
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DRF Pagination with custom ViewSet

[Xavier Ordoquy]

Hi Angus,

The first thing would be to fire django debug toolbar and investigate whether 
the pagination is passed to the context.
If it isn’t there’s something in your code that prevents it.
If it is, you’ll have to go through the templates to figure.

Regards,
Xavier Ordoquy,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why is it showing a hashed password?

[Xavier Ordoquy]

Hi,

> Le 15 mars 2017 à 08:06, CocaCola  a écrit :
> 
> Even if there is no security problem..
> The hashed password is meaningless value.
> Why is it showing a hashed password?

This is the expected behavior.
For one thing, it’s a security issue to store passwords clear in the DB. Django 
stores it encrypted to avoid this.
Second thing, DRF tries hard to return the most meaningful data. In that case, 
DRF won’t be returning what has been given. Instead it’ll get the data from the 
DB and return them, which implies the password is encrypted.

> of course i know how to remove password at response .
> by manipulating returndict..

To my opinion, the best option is to set the field as write only.

> another way, i can use a serializer with fields without a password, 
> but it will not be validated, so additional manipulation is required.

Not sure what you mean by that.

> Why is not it the default setting to hide the (hashed) 'password' field of 
> AbstractBaseUser?

Because it’s the developer job to design the API and take those decision / 
actions.
The framework may provide guidance but won’t replace human.
I’ve tried to make things automated (and half magic there) with nested 
serializer in 2.x and it didn’t work at all. I really love the 3.x approach to 
leave it to the dev.

I’ve seen a lot of bad feedback on REST API which were caused by bad design 
decisions or even lack of thoughts from the development team.

API needs to be designed.
It’s HARD and time consuming.
It requires knowledge and deep understanding of the requirements.

Regards,
Xavier Ordoquy,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: import error in tutorial quickstart

[Xavier Ordoquy]

Hi madame,

You have missed the trailing dot in this part in the tutorial:

django-admin.py startproject tutorial .  # Note the trailing '.' character

Regards,
Xavier Ordoquy,
Linovia.


> Le 13 mars 2017 à 07:06, Tony Wang  a écrit :
> 
> Hi Guys
> 
> Have you guys tested the code in quickstart? There seems be to an import 
> error . It will run well when removed tutorial (Marked italic and red).
> 
> 
> Environment:
> 
> 
> Request Method: GET
> Request URL: http://10.211.55.12:8000/users/1/
> 
> Django Version: 1.8.13
> Python Version: 2.7.12
> Installed Applications:
> ('django.contrib.admin',
>  'django.contrib.auth',
>  'django.contrib.contenttypes',
>  'django.contrib.sessions',
>  'django.contrib.messages',
>  'django.contrib.staticfiles',
>  'rest_framework',
>  'restapp')
> Installed Middleware:
> ('django.contrib.sessions.middleware.SessionMiddleware',
>  'django.middleware.common.CommonMiddleware',
>  'django.middleware.csrf.CsrfViewMiddleware',
>  'django.contrib.auth.middleware.AuthenticationMiddleware',
>  'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
>  'django.contrib.messages.middleware.MessageMiddleware',
>  'django.middleware.clickjacking.XFrameOptionsMiddleware',
>  'django.middleware.security.SecurityMiddleware')
> 
> 
> Traceback:
> File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py" in 
> get_response
>   119. resolver_match = resolver.resolve(request.path_info)
> File "/usr/local/lib/python2.7/dist-packages/django/core/urlresolvers.py" in 
> resolve
>   365. for pattern in self.url_patterns:
> File "/usr/local/lib/python2.7/dist-packages/django/core/urlresolvers.py" in 
> url_patterns
>   401. patterns = getattr(self.urlconf_module, "urlpatterns", 
> self.urlconf_module)
> File "/usr/local/lib/python2.7/dist-packages/django/core/urlresolvers.py" in 
> urlconf_module
>   395. self._urlconf_module = import_module(self.urlconf_name)
> File "/usr/lib/python2.7/importlib/__init__.py" in import_module
>   37. __import__(name)
> File "/root/rest_example/rest_example/urls.py" in 
>   18. from restapp import views
> File "/root/rest_example/restapp/views.py" in 
>   3. from tutorial.quickstart.serializers import UserSerializer, 
> GroupSerializer
> 
> Exception Type: ImportError at /users/1/
> Exception Value: No module named tutorial.quickstart.serializers
> 
> 
> 
> 
> http://www.django-rest-framework.org/tutorial/quickstart/
> 
> from django.contrib.auth.models import User, Group
> from rest_framework import viewsets
> from tutorial.quickstart.serializers import UserSerializer, GroupSerializer
> 
> 
> class UserViewSet(viewsets.ModelViewSet):
> """
> API endpoint that allows users to be viewed or edited.
> """
> queryset = User.objects.all().order_by('-date_joined')
> serializer_class = UserSerializer
> 
> 
> class GroupViewSet(viewsets.ModelViewSet):
> """
> API endpoint that allows groups to be viewed or edited.
> """
> queryset = Group.objects.all()
> serializer_class = GroupSerializer
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with Built in API Docs

[Xavier Ordoquy]

Provided we have a couple of issue ongoing or already fixed on the current 
issue, I’d expect another release to be out soon, but I have no idea how soon.
Meanwhile, installing from master should do. We’ll be focusing on bug fixing in 
the short term.

Regards,
Xavier Ordoquy,
Linovia.


> Le 10 mars 2017 à 13:19, Abu Ashraf Masnun  a écrit :
> 
> What would be the recommended way to apply the fix? Install from master? Or 
> should it be available from pip soon? 
> 
> On Fri, Mar 10, 2017 at 6:17 PM, Xavier Ordoquy  <mailto:xordo...@linovia.com>> wrote:
> Hi,
> 
> Thanks for raising this.
> This has been reported and fixed 
> (https://github.com/tomchristie/django-rest-framework/issues/4952 
> <https://github.com/tomchristie/django-rest-framework/issues/4952>).
> 
> Regards,
> Xavier Ordoquy,
> Linovia.
> 
>> Le 10 mars 2017 à 13:11, Abu Ashraf Masnun > <mailto:mas...@gmail.com>> a écrit :
>> 
>> I am trying out the new automated API docs and came across this weird issue 
>> - when I click the "Interact" button, it pops up but instead of the html 
>> form on the right side, I see the raw html instead. 
>> 
>> Screenshot:  http://i.imgur.com/P9dneSi.png <http://i.imgur.com/P9dneSi.png>
>> 
>> Clicking "Send Request" works fine. It loads the response. But still the 
>> html on the right side. Am I missing something?
>> 
>> These are the versions: 
>> 
>> coreapi==2.3.0
>> Django==1.10.5
>> djangorestframework==3.6.1
>> 
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django REST framework" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-rest-framework+unsubscr...@googlegroups.com 
>> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Django REST framework" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/django-rest-framework/UBRPpvTJRVY/unsubscribe
>  
> <https://groups.google.com/d/topic/django-rest-framework/UBRPpvTJRVY/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> 
> 
> -- 
> Abu Ashraf Masnun | +8801711960803 | http://masnun.me <http://masnun.me/>
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with Built in API Docs

[Xavier Ordoquy]

Hi,

Thanks for raising this.
This has been reported and fixed 
(https://github.com/tomchristie/django-rest-framework/issues/4952 
<https://github.com/tomchristie/django-rest-framework/issues/4952>).

Regards,
Xavier Ordoquy,
Linovia.

> Le 10 mars 2017 à 13:11, Abu Ashraf Masnun  a écrit :
> 
> I am trying out the new automated API docs and came across this weird issue - 
> when I click the "Interact" button, it pops up but instead of the html form 
> on the right side, I see the raw html instead. 
> 
> Screenshot:  http://i.imgur.com/P9dneSi.png
> 
> Clicking "Send Request" works fine. It loads the response. But still the html 
> on the right side. Am I missing something?
> 
> These are the versions: 
> 
> coreapi==2.3.0
> Django==1.10.5
> djangorestframework==3.6.1
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tutorial 1 - JSONResponse

[Xavier Ordoquy]

Hi,

You just made a good point ;)
The tutorial was written way before JSONResponse was introduced in Django.
I just checked this was introduced in Django 1.7. Since DRF now supports 1.8+ 
we could use Django’s JSONResponse indeed.

Regards,
Xavier Ordoquy,
Linovia.

> Le 20 févr. 2017 à 09:40, Anupam Jain  a écrit :
> 
> I was going through the tutorial-1 here 
> <http://www.django-rest-framework.org/tutorial/1-serialization/#writing-regular-django-views-using-our-serializer>.
>  Can we not directly use Django's JSONResponse 
> <https://docs.djangoproject.com/en/1.10/ref/request-response/#jsonresponse-objects>
>  class here instead of declaring it separately?
> 
> (I may be missing something since just getting started with DRF)
> 
> thanks
> Anupam
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: version 3.5.4 of drf and Python 3.4 support

[Xavier Ordoquy]

And will still test against 3.4 for Django 1.11
The commit you mentioned earlier is for django master which will be the release 
after 1.11
cf https://docs.djangoproject.com/en/dev/releases/2.0/#python-compatibility 
<https://docs.djangoproject.com/en/dev/releases/2.0/#python-compatibility>

Regards,
Xavier Ordoquy;
Linovia.

> Le 17 févr. 2017 à 12:57, vidja.hun...@gmail.com a écrit :
> 
> Thanks,
> 
> taken from the django docs: 
> https://docs.djangoproject.com/en/1.10/faq/install/
> The upcoming Django 1.11 will support python 3.4, so is dropping 3.4 
> compatibility not a bit preliminary, 
> especially since many people are running enterprise or LTS distributions that 
> not yet ship with python 3.5+
> 
> regards,
> 
> Vid
> 
> On Friday, February 17, 2017 at 12:28:49 PM UTC+1, Xavier Ordoquy wrote:
> Hi,
> 
> We support the Python versions that the supported Django version supports.
> If DRF droped 3.4 it means Django also dropped it.
> We can’t guarantee it will work or will not work. This is up to you to ensure 
> you don’t have issues.
> 
> Regards,
> Xavier Ordoquy,
> Linovia. 
> 
>> Le 17 févr. 2017 à 11:15, vidja@gmail.com  a écrit :
>> 
>> I saw on commit 7d4706f that python 3.4 was dropped from the tox tests, but 
>> pypi still states that python 3.4 is supported.
>> Will v3.5.4 still work on python 3.4 and if not what functionality would 
>> break? Any view on the compatibility road map would help our planning.
>> 
>> Vid
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django REST framework" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-rest-framework+unsubscr...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: version 3.5.4 of drf and Python 3.4 support

[Xavier Ordoquy]

Hi,

We support the Python versions that the supported Django version supports.
If DRF droped 3.4 it means Django also dropped it.
We can’t guarantee it will work or will not work. This is up to you to ensure 
you don’t have issues.

Regards,
Xavier Ordoquy,
Linovia. 

> Le 17 févr. 2017 à 11:15, vidja.hun...@gmail.com a écrit :
> 
> I saw on commit 7d4706f that python 3.4 was dropped from the tox tests, but 
> pypi still states that python 3.4 is supported.
> Will v3.5.4 still work on python 3.4 and if not what functionality would 
> break? Any view on the compatibility road map would help our planning.
> 
> Vid
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pagination and Filtering

[Xavier Ordoquy]

This looks more like you’ve set a list for pagination class for that view.
What does your view looks like ?

Regards,
Xavier Ordoquy,
Linovia.

> Le 2 févr. 2017 à 16:09, Thiago Mambretti  a écrit :
> 
> Sorry,
> 
> The error I'm getting is the following:
> 
> 
> Environment:
> 
> Request Method: GET
> Request URL: http://192.168.1.208:8000/api/states/
> 
> Django Version: 1.10.5
> Python Version: 2.7.6
> Installed Applications:
> ['django.contrib.admin',
>  'django.contrib.auth',
>  'django.contrib.contenttypes',
>  'django.contrib.sessions',
>  'django.contrib.messages',
>  'django.contrib.staticfiles',
>  'rest_framework',
>  'crispy_forms',
>  'apps.geodata',
>  'apps.accounts']
> Installed Middleware:
> ['django.middleware.security.SecurityMiddleware',
>  'django.contrib.sessions.middleware.SessionMiddleware',
>  'django.middleware.common.CommonMiddleware',
>  'django.middleware.csrf.CsrfViewMiddleware',
>  'django.contrib.auth.middleware.AuthenticationMiddleware',
>  'django.contrib.messages.middleware.MessageMiddleware',
>  'django.middleware.clickjacking.XFrameOptionsMiddleware']
> 
> 
> 
> Traceback:
> 
> File 
> "/home/vagrant/.virtualenvs/prospect/local/lib/python2.7/site-packages/django/core/handlers/exception.py"
>  in inner
>   39. response = get_response(request)
> 
> File 
> "/home/vagrant/.virtualenvs/prospect/local/lib/python2.7/site-packages/django/core/handlers/base.py"
>  in _get_response
>   187. response = self.process_exception_by_middleware(e, 
> request)
> 
> File 
> "/home/vagrant/.virtualenvs/prospect/local/lib/python2.7/site-packages/django/core/handlers/base.py"
>  in _get_response
>   185. response = wrapped_callback(request, *callback_args, 
> **callback_kwargs)
> 
> File 
> "/home/vagrant/.virtualenvs/prospect/local/lib/python2.7/site-packages/django/views/decorators/csrf.py"
>  in wrapped_view
>   58. return view_func(*args, **kwargs)
> 
> File 
> "/home/vagrant/.virtualenvs/prospect/local/lib/python2.7/site-packages/rest_framework/viewsets.py"
>  in view
>   83. return self.dispatch(request, *args, **kwargs)
> 
> File 
> "/home/vagrant/.virtualenvs/prospect/local/lib/python2.7/site-packages/rest_framework/views.py"
>  in dispatch
>   477. response = self.handle_exception(exc)
> 
> File 
> "/home/vagrant/.virtualenvs/prospect/local/lib/python2.7/site-packages/rest_framework/views.py"
>  in handle_exception
>   437. self.raise_uncaught_exception(exc)
> 
> File 
> "/home/vagrant/.virtualenvs/prospect/local/lib/python2.7/site-packages/rest_framework/views.py"
>  in dispatch
>   474. response = handler(request, *args, **kwargs)
> 
> File 
> "/home/vagrant/.virtualenvs/prospect/local/lib/python2.7/site-packages/rest_framework/mixins.py"
>  in list
>   42. page = self.paginate_queryset(queryset)
> 
> File 
> "/home/vagrant/.virtualenvs/prospect/local/lib/python2.7/site-packages/rest_framework/generics.py"
>  in paginate_queryset
>   170. if self.paginator is None:
> 
> File 
> "/home/vagrant/.virtualenvs/prospect/local/lib/python2.7/site-packages/rest_framework/generics.py"
>  in paginator
>   163. self._paginator = self.pagination_class()
> 
> Exception Type: TypeError at /api/states/
> Exception Value: 'list' object is not callable
> 
> 
> 
> 
> 
> 
> 
> 
> On Thursday, February 2, 2017 at 12:07:00 PM UTC-3, Thiago Mambretti wrote:
> Hi all,
> 
> Is it possible to use the default pagination backend along with the following 
> filters?
> 
> 'django_filters.rest_framework.DjangoFilterBackend',
> 'rest_framework.filters.SearchFilter',
> 'rest_framework.filters.OrderingFilter',
> 
> I'm using a ModelViewSet and the API only when I have only the pagination or 
> the filters activated.
> 
> There's no mention on anything about it on the docs so came here for help.
> 
> Thanks,
> 
>  
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pagination and Filtering

[Xavier Ordoquy]

Hi,

I can’t think of a reason why they wouldn’t work in particular  if the 
documentation doesn’t says otherwise.
Any specific issue that makes you think they don’t ?

Regards,
Xavier Ordoquy,
Linovia.

> Le 2 févr. 2017 à 16:07, Thiago Mambretti  <mailto:wdthi...@gmail.com>> a écrit :
> 
> Hi all,
> 
> Is it possible to use the default pagination backend along with the following 
> filters?
> 
> 'django_filters.rest_framework.DjangoFilterBackend',
> 'rest_framework.filters.SearchFilter',
> 'rest_framework.filters.OrderingFilter',
> 
> I'm using a ModelViewSet and the API only when I have only the pagination or 
> the filters activated.
> 
> There's no mention on anything about it on the docs so came here for help.
> 
> Thanks,
> 
>  
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: slow query viewset query

[Xavier Ordoquy]

> Le 11 janv. 2017 à 20:21, Mark Mikofski  a écrit :
> 
> Thanks for your answer. So the slow performance issue occurs whether the 
> request is performed using JSON or from the browseable API. 

No, only this the browsable API.

> 
> >>> import requests
> >>> PARAMS = {'latitude': 38.2, 'longitude': -122.1}
> >>> requests.get(url=URL, auth=AUTH, params=dict(PARAMS, limit=1000))
> # 1 loop, best of 3: 4.21 s per loop - using %timeit
> 

This isn’t a JSON request so it’ll trigger the browsable API.

> We do have django-filters with cripy-forms in installed apps, and it is 
> listed as the default backend in the viewset:
> 
> filter_backends = (filters.DjangoFilterBackend,)
> 
> but would that be the cause of the issue? we will remove it, but it seems 
> unlikely.

Your mileage may vary but it is likely.

> 
> Any ideas where we should debug or profile?

Activate the logging for Django’s DB queries.

> 
> when I mock the request and render the JSON manually, I get a response in 
> 677[ms], this includes getting the queryset 757[microseconds] and 
> serialization 57[microseconds], so this is what we expect. Also our previous 
> API which is ASP.NET + MSSQL is about 600[ms] roundtrip.
> 
> Thanks again!
> 
> On Wednesday, January 11, 2017 at 1:00:56 AM UTC-8, Xavier Ordoquy wrote:
> Hi,
> 
> It’s likely either the displayed filter or the create/update form from the 
> browsable API that spans some relation and gets the UI slow.
> Try to perform the same request as JSON that should validate the previous 
> assomption.
> 
> Regards,
> Xavier Ordoquy,
> Linovia.
> 
>> Le 11 janv. 2017 à 09:20, Mark Mikofski > a 
>> écrit :
>> 
>> We are experiencing very slow performance from one view in the API that 
>> returns a queryset of a filter. We expected 0.5 - 1.0 sec, but the request 
>> is taking up to 4 seconds. Turning off pagination decreases the wait to 2 
>> sec.
>> 
>> From the Django shell, the query is extremely fast, < 0.001 sec.
>> 
>> >>> from django.db.models import F
>> >>> from app.models import Weather
>> >>> import numpy as np
>> >>> R_EARTH = 6371000.0  # [m] earth's radius
>> >>> search_radius = 160934
>> >>> latitude, longitude = 38.1, -122.1
>> >>> dtheta = np.rad2deg(search_radius / R_EARTH)  # [degrees]
>> >>> queryset = Weather.objects.filter(
>> ... latitude__range=(latitude - dtheta, latitude + dtheta),
>> ... longitude__range=(longitude - dtheta, longitude + dtheta),
>> ... data_type__in=Weather.ALL_DATA_TYPES
>> ... ).annotate(distance_d=(
>> ... (F('latitude') - latitude) ** 2 + (F('longitude') - longitude) ** 2)
>> ... ).order_by('distance_d').exclude(distance_d__gt=(dtheta ** 2))
>> # 1000 loops, best of 3: 737 µs per loop - using %timeit
>> 
>> I tested serializing the queryset and rendering the response, and It is 
>> still very fast, < 1 sec
>> 
>> # I know there is an easier/better way to do this, sorry :(
>> >>> from django.http import HttpRequest
>> >>> from rest_framework.request import Request
>> >>> from app.serializers import WeatherSearchSerializer
>> >>> request = Request(HttpRequest())
>> >>> request.META['SERVER_NAME'] = u'localhost'
>> >>> request.META['SERVER_PORT'] = 8000
>> >>> w = WeatherSearchSerializer(queryset, context={'request': request}, 
>> >>> many=True)
>> # 1 loops, best of 3: 56.5 µs per loop - using %timeit
>> >>> jsondata = JSONRenderer().render(w.data)
>> # 1 loops, best of 3: 677 ms per loop - using %timeit
>> 
>> But if I use the browseable API or send a request, it takes 3-4 seconds.
>> 
>> >>> import requests
>> >>> PARAMS = {'latitude': 38.2, 'longitude': -122.1}
>> >>> requests.get(url=URL, auth=AUTH, params=dict(PARAMS, limit=1000))
>> # 1 loop, best of 3: 4.21 s per loop - using %timeit
>> 
>> requirements:
>> Django>=1.8.5
>> djangorestframework>=3.3.3
>> psycopg2>=2.6.2
>> django-storages>=1.4
>> boto>=2.38.0
>> django-crispy-forms>=1.6.0
>> django-filter>=0.14.0
>> 
>> platform: AWS
>> EC2: c3.4xlarge instance based on  Oracle Linux 7.2
>> RDS: Postgres on a db.m3.medium instance with 1TB of storage
>> S3
>> software: Apache httpd with mod_wsgi and python-2.7
>> 
>> models

Re: URL wih dot in Django Rest Framework

[Xavier Ordoquy]

This is similar to issue #4341

Regards,
Xavier Ordoquy,
Linovia.

> Le 11 janv. 2017 à 00:58, Bernardo Garcia  a écrit :
> 
> I have the following model with a primary_key=True specified: 
> 
> class Team(models.Model):
> name = models.CharField(
> max_length=64,
> primary_key=True,
> )
> ... other fields
> 
> When I serialize this model, I do the following:
> 
> class TeamSerializer(serializers.ModelSerializer):
>class Meta:
> model = Team
> fields = ('url', 'name',) # and another fields
> 
> 
> My viewset:
> 
> class TeamViewSet(viewsets.ModelViewSet):
> lookup_value_regex = '[-\w.]'
> queryset = Team.objects.all()
> serializer_class = TeamSerializer
> filter_fields = ('name',) # and another fields
> 
> My urls.py:
> 
> router = routers.DefaultRouter()
> router.register(r'teams', TeamViewSet)
> 
> urlpatterns = [
> url(r'^api/', include(router.urls)),
> 
> # I am not sure if this url is right. I repeat of include(router.urls)
> url(r'^api/teams/(?P[-\w.]+)/', include(router.urls)),
> 
> url(r'^api-auth/', include('rest_framework.urls', 
> namespace='rest_framework'))
> ]
> 
> Then, when I create a Team object with name attribute containing dot ., for 
> example Latinos F.C. and I go to the rest url, I get:
> 
>  <https://i.stack.imgur.com/yta0M.jpg>
> 
> 
> I am not sure about of how to use the lookup_value_regex attribute in my 
> viewset. In this answer <http://stackoverflow.com/a/27966110/2773461> is used 
> with some basic regex, but if I use it, any Team object is reachable via my 
> serialized Rest API.
> 
> How to can I get a url like as: /api/teams/Name.F.C. in my serialized Team 
> model?
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: slow query viewset query

[Xavier Ordoquy]

Hi,

It’s likely either the displayed filter or the create/update form from the 
browsable API that spans some relation and gets the UI slow.
Try to perform the same request as JSON that should validate the previous 
assomption.

Regards,
Xavier Ordoquy,
Linovia.

> Le 11 janv. 2017 à 09:20, Mark Mikofski  a écrit :
> 
> We are experiencing very slow performance from one view in the API that 
> returns a queryset of a filter. We expected 0.5 - 1.0 sec, but the request is 
> taking up to 4 seconds. Turning off pagination decreases the wait to 2 sec.
> 
> From the Django shell, the query is extremely fast, < 0.001 sec.
> 
> >>> from django.db.models import F
> >>> from app.models import Weather
> >>> import numpy as np
> >>> R_EARTH = 6371000.0  # [m] earth's radius
> >>> search_radius = 160934
> >>> latitude, longitude = 38.1, -122.1
> >>> dtheta = np.rad2deg(search_radius / R_EARTH)  # [degrees]
> >>> queryset = Weather.objects.filter(
> ... latitude__range=(latitude - dtheta, latitude + dtheta),
> ... longitude__range=(longitude - dtheta, longitude + dtheta),
> ... data_type__in=Weather.ALL_DATA_TYPES
> ... ).annotate(distance_d=(
> ... (F('latitude') - latitude) ** 2 + (F('longitude') - longitude) ** 2)
> ... ).order_by('distance_d').exclude(distance_d__gt=(dtheta ** 2))
> # 1000 loops, best of 3: 737 µs per loop - using %timeit
> 
> I tested serializing the queryset and rendering the response, and It is still 
> very fast, < 1 sec
> 
> # I know there is an easier/better way to do this, sorry :(
> >>> from django.http import HttpRequest
> >>> from rest_framework.request import Request
> >>> from app.serializers import WeatherSearchSerializer
> >>> request = Request(HttpRequest())
> >>> request.META['SERVER_NAME'] = u'localhost'
> >>> request.META['SERVER_PORT'] = 8000
> >>> w = WeatherSearchSerializer(queryset, context={'request': request}, 
> >>> many=True)
> # 1 loops, best of 3: 56.5 µs per loop - using %timeit
> >>> jsondata = JSONRenderer().render(w.data)
> # 1 loops, best of 3: 677 ms per loop - using %timeit
> 
> But if I use the browseable API or send a request, it takes 3-4 seconds.
> 
> >>> import requests
> >>> PARAMS = {'latitude': 38.2, 'longitude': -122.1}
> >>> requests.get(url=URL, auth=AUTH, params=dict(PARAMS, limit=1000))
> # 1 loop, best of 3: 4.21 s per loop - using %timeit
> 
> requirements:
> Django>=1.8.5
> djangorestframework>=3.3.3
> psycopg2>=2.6.2
> django-storages>=1.4
> boto>=2.38.0
> django-crispy-forms>=1.6.0
> django-filter>=0.14.0
> 
> platform: AWS
> EC2: c3.4xlarge instance based on  Oracle Linux 7.2
> RDS: Postgres on a db.m3.medium instance with 1TB of storage
> S3
> software: Apache httpd with mod_wsgi and python-2.7
> 
> models and serializers: totally vanilla, nothing custom
> * serializer is `serializers.HyperlinkedModelSerializer`
> 
> views: totaly vanilla, nothing custom
> * view uses `viewsets.ModelViewSet`
> 
> Any ideas where the extra seconds are coming from? I'm not sure where to 
> profile. Any assistance would be greatly appreciated.
> 
> Other relevant posts:
> * 
> https://groups.google.com/d/msg/django-rest-framework/AkLKdfxCrcU/qyOB1k37pJAJ
> * that's all I could find search terms: slow queryset
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Include drf-based package to section "documenting your api"

[Xavier Ordoquy]

> Le 28 déc. 2016 à 17:31, Alex Mashianov  a écrit :
> 
> Hello, i've created new package for automated api documentation.
> 
> Could it be included in rest_frameworks own documentation under topic 
> "documenting your api"?
> 
> https://github.com/iMakedonsky/drf-autodocs
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> <mailto:django-rest-framework+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

Sure, you need to make a PR for that. It should be explained in the 3rd party 
section of the documentation.

Regards,
Xavier Ordoquy,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: combine two queryset to one Serializers

[Xavier Ordoquy]

Hi

> Le 22 déc. 2016 à 06:58, korea k  a écrit :
> 
>  class PostSet(models.Model):
>   title = models.CharField(max_length=50, verbose_name=u'title')
>   introduce = models.CharField(u'introduce', max_length=50)
> 
> class Post(model.Model):
>   title = models.CharField(max_length=50, verbose_name=u'title')
>   introduce = models.CharField(u'introduce', max_length=50)
> 
> 
> class ShowSerialzer(serializers.Serialize):
> title = serializers.CharField()
> introduce = serializers.CharField()
> 
> 
> post = Post.objects.all()
> post_set = PostSet.objects.all()
> 
> How I can comebine two queryset( as above post, post_set ) from two different 
> model combine to one ShowSerialzer?
> 

It’s as simple as adding query sets together:

full_data = list(post) + list(post_set)
ShowSerialzer(data=full_data)

Regards,
Xavier Ordoquy,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Serializer and Django Model

[Xavier Ordoquy]

Hi

> Le 22 déc. 2016 à 07:08, korea k  a écrit :
> 
> Recently, I use DRF to write API.I found it's there is a so tight releation 
> between Django Model and DRF serializer.

Nope. DRF serializers are independent from Django Models. ModelSerializers are 
not.

> Especially, ModelSerializer.  Can anyone  show me some more detail about it?

What kind of detail do you need ?

> How you guys thinking when desgin DRF?

Focus on the representation of the ressource. REST is about REpresentational 
State Transfer.

> Or maybe I shoule downloads old version of DRF to understand better

What would that change the understanding ?

Regards,
Xavier Ordoquy,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Custom Related Field proper usage?

[Xavier Ordoquy]

> Le 13 déc. 2016 à 20:58, Lev Avakian  a écrit :
> 
> I have a a UserProfile model that has a OneToOne with a the 
> django.contrib.auth User and looks something like this:
> 
> class UserProfile(BaseModel):
> # Authentication information
> email = models.OneToOneField(
> User, to_field='username', db_index=True, unique=True, 
> related_name='profile', on_delete=models.CASCADE
> )
> 
> I have another model that has a relation to a UserProfile and looks something 
> like this:
> 
> class Something(BaseModel):
> user = models.ForeignKey(
> 'UserProfile', to_field='email', related_name='something', 
> db_index=True, null=True, on_delete=models.SET_NULL,
> )
> 
> I have made a custom relational field that looks like this:
> 
> class UserProfileField(serializers.RelatedField):
> queryset = UserProfile.objects.all()
> 
> def to_representation(self, value):
> return value.email.username
> 
> def to_internal_value(self, data):
> try:
> return 
> UserProfile.objects.get(email=User.objects.get(username=data))
> except (User.DoesNotExist, UserProfile.DoesNotExist):
> raise serializers.ValidationError("User '" + str(data) + "' does 
> not exist.")
> 
> The serializer for Something looks like this:
> 
> class SomethingSerializer(serializers.ModelSerializer):
> user = UserProfileField(required=True)
> 
> class Meta:
> model = Something
> 
> The idea here is that when sending a request to Something, you should be able 
> to just do:
> {
>   "user": "myusernameh...@email.com"
> }
> 
> rather than:
> {
>   "user": {"email": "myusernameh...@email.com"}
> }
> 
> The good news is that this works, the bad news is that it is rife with race 
> conditions and integrity errors, since the 
> to_representation/to_internal_value checks aren't done atomically with the 
> serializer save/create (and take long enough that during testing it's quite 
> common to run into these race conditions).
> 
> Is there a more correct way of achieving that flat serializer representation, 
> and is this a gross misuse of custom relational fields?

Hi,

You’re probably looking at the SlugRelatedField 
(http://www.django-rest-framework.org/api-guide/relations/#slugrelatedfield 
)
Not sure what you mean when you mention your race condition and integrity 
errors. Could you be more explicit about them ?

Regards,
Xavier,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ModelSerializer doesn't hit update method

[Xavier Ordoquy]

Hi

> Le 30 nov. 2016 à 05:04, Ashutosh Das  a écrit :
> 
> Here is my model:
> 
> class Movie(models.Model):
> name = models.CharField(max_length=800, unique=True)
> imdb_rating = models.IntegerField(null=True)
> movie_choice = (
> ('Act', 'Action'),
>   ...
> )
> movie_type = models.CharField(max_length=3, choices=movie_choice)
> created_at = models.DateTimeField(auto_now_add=True)
> updated_at = models.DateTimeField(auto_now=True)
> 
> 
> class Hiren(models.Model):
> movie = models.ForeignKey(Movie)
> watched_full = models.BooleanField(default=True)
> rating = models.IntegerField()
> source = models.CharField(max_length=500, null=True)
> watched_at = models.DateField()
> quality_choice = (
> ('HD', 'HD'),
> ..
> )
> video_quality = models.CharField(max_length=3, choices=quality_choice)
> created_at = models.DateField(auto_now_add=True)
> updated_at = models.DateField(auto_now=True)
> 
> and my serializer:
> 
> class MovieSerializer(serializers.ModelSerializer):
> class Meta:
> model = Movie
> fields = '__all__'
> 
> 
> class HirenSerializer(serializers.ModelSerializer):
> movie = MovieSerializer()
> 
> class Meta:
> model = Hiren
> fields = ('movie', 'id', 'watched_full', 'rating', 'source', 
> 'video_quality', 'watched_at')
> 
> def create(self, validated_data):
> movie_data = validated_data.pop('movie')
> movie = Movie.objects.create(**movie_data)
> hiren = Hiren.objects.create(movie=movie, **validated_data)
> return hiren
> 
> def update(self, instance, validated_data):
> print('hit')  # doesn't print anything on put type request
> movie_name = validated_data.get('movie', {}).get('name')
> # print(movie_name)
> # print(instance.movie.name)
> 
> if movie_name != instance.movie.name:
> instance.movie.name = movie_name
> # instance.movie.name = validated_data.get('movie', {}).get('name')
> instance.movie.imdb_rating = validated_data.get('movie', 
> {}).get('imdb_rating')
> instance.movie.movie_type = validated_data.get('movie', 
> {}).get('movie_type')
> instance.watched_full = validated_data.get('watched_full', 
> instance.watched_full)
> instance.rating = validated_data.get('rating', instance.rating)
> instance.source = validated_data.get('source', instance.source)
> instance.video_quality = validated_data.get('video_quality', 
> instance.video_quality)
> instance.watched_at = validated_data.get('watched_at', 
> instance.watched_at)
> # instance.movie.save()
> instance.save()
> 
> return instance
> 
> When I try to update the data without changing the "name" its throws an error:
> { "movie": { "name": [ "movie with this name already exists." ] } }
> 
> So I try to fix this via those lines:
> if movie_name != instance.movie.name:
> instance.movie.name = movie_name
> 
> But it turns out that put request doesn't hit the update method at all.
There’s no reason update will be hit when the serializer doesn’t validate the 
data.

I wrote something about this kind of issue at 
https://medium.com/django-rest-framework/dealing-with-unique-constraints-in-nested-serializers-dade33b831d9
 


Regards,
Xavier,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: I need to Filter from multiple tables return a json response

[Xavier Ordoquy]

Hi,

> Le 23 nov. 2016 à 07:04, pradam.programm...@gmail.com a écrit :
> 
> I need to Filter from multiple tables and return response like this [ {'first 
> name':'Max',','last name':'Yuri','age':23,'gender':'Male'},{'first 
> name':'Alex',','last name':'John','age':23,'gender':'Male'}]
> in rest framework.
> here 
> 1.first name and last name come from django 'auth.User' table
> 2.age and gender comes from another table
> 
> how can i stitch these tables return response as specified above in rest 
> framework.
> i can able to do it in custom API but i dont know in rest framework.Please 
> Help Me ?
> 
> Thank You.

Everything you need should be in 
http://www.django-rest-framework.org/api-guide/filtering/ 

If you’re not sure how spanning across tables with Django, I recommend you read 
this section: 
https://docs.djangoproject.com/en/1.10/topics/db/models/#many-to-many-relationships
 


Regards,
Xavier,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Nesting DRF ViewSets

[Xavier Ordoquy]

Hi,

> Le 17 nov. 2016 à 09:10, Ryan Sears  > a écrit :
> 
> Hi folks!
> 
> I've got a question on nesting viewsets properly to have different permission 
> classes/contexts. Any extra eyes would be greatly appreciated, as it's been 
> open for about a week and I'm not confident that any of the solutions 
> proposed are the "right" way to accomplish what I'm trying to do! 
> 
> http://stackoverflow.com/questions/40455229/nesting-viewset-routes-in-drf 
> 
> 
> Cheers,
> Ryan

We usually advice not to nested routes.
ReST API expose resources. Nesting routes means that you don’t have direct 
access to those resources which makes things more complex for the client, 
breaks automated generations and duplicates entry points for the same resource 
(which is similar to breaking DRY). There are probably other points too.

As mentioned on SO,  https://github.com/alanjds/drf-nested-routers 
 should do. As you think it’s 
overkill, you may want to look at the source and take whatever you want if you 
still want to go in that direction.

Regards,
Xavier,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pagination In APIView.

[Xavier Ordoquy]

The pagination is explained 
at 
http://www.django-rest-framework.org/api-guide/pagination/#pagenumberpagination 
and the configuration on a per view basis is in the second part 
of 
http://www.django-rest-framework.org/api-guide/pagination/#setting-the-pagination-style

Regards,
Xavier Ordoquy,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Rest Framework - Could not resolve URL for hyperlinked relationship using view name “field-detail”

[Xavier Ordoquy]

Hi,

You declared your view as "fields" in the routers, so you should use 
"fields-detail" as the view name for the hyperlink.

Regards,
Xavier,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Browsable API and Versioning

[Xavier Ordoquy]

Hi Robyn,

> Le 3 nov. 2016 à 21:22, Robyn Smith  a écrit :
> 
> Hello Everyone!
> 
> DRF is amazing. Just a quick thank you to the community!
> 
> I'm working on a project where we're building an API from scratch using the 
> Django REST Framework, and when working on the Proof of Concept, we started 
> running into challenges when we introduced Accept Header based versioning. 
> 
> Does anyone know how versioning and the browsable API are supposed to work? 
> I'm not really able to find anything documented.

I don’t think there’s anything yet in the browsable API that supports the 
versioning through headers unfortunately.
I’m afraid in the short term you’ll have to insert them yourself with your 
browser.

Regards,
Xavier,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: getting interface error after changing the DB connection details

[Xavier Ordoquy]

Hi,

> Le 26 oct. 2016 à 14:28, Raghunath Raghava  a écrit :
> 
> Hi All,
> 
> I am having the following " interface error : not connected"  to the DB while 
> connecting to the DB through DRF.
> 
> whereas I have written a separate test class for connection to the DB  it 
> works fine , but when I am trying to do it using the DRF I am getting issues 
> . I am using the cx_oracle driver for getting connected.
> 
> the test connection when I run works fine
> 
> $> /usr/local/bin/python testDBConn.py
> select count(*) from boa_packages
> [(3,)]
> 
> but the same DB credentials when I am working with the DRF , its giving me 
> the error , can someone point me to the issue
> 
> mycursor.execute(sqlqry)
> InterfaceError: not connected
> 
> I have set the LD_LIBRARY_PATH in the same python script using os.environ , 
> should I use something else. Appreciate some help in this regard.
> further earlier the same code used to work perfectly when I was connecting to 
> a testDB , but now I am trying to connect to the production DB which is where 
> the issue is.
> 
> thanks 
> Raghu 

DRF uses the Django ORM layer and has no specific code for the databases.
You’ll probably have more answers on the Django mailing list itself.

Regards,
Xavier,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Model serializer factory

[Xavier Ordoquy]

Hi,

> Le 24 oct. 2016 à 14:27, Горобец Дмитрий  a écrit :
> 
> Hello,
> 
> Is there a shortcut for making dynamic model serializers like 
> modelform_factory?

No, there’s no such thing for now.
However, as you can see from the model form_factory sources, it shouldn’t be 
too hard to do something similar.

Regards,
Xavier,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django REST framework 3.4.7 not support RequestsClient

[Xavier Ordoquy]

Hi,

It seems that the DRF documentation was updated ahead the 3.5 release.
If it still doesn’t work, please upgrade to the 3.5 release.

> Le 21 oct. 2016 à 11:19, korea k  a écrit :
> 
> oh，I guess so.
> thanks  a million for your answering.
> smile~
> 
> 在 2016年10月20日星期四 UTC+8下午4:10:26，Tom Christie写道：
> Okay, this is my fault in accidentally deploying the documentation from 
> master, which includes some of the upcoming 3.5 features.
> The RequestsClient is now available in REST framework master, and the 3.5 
> release should be out very shortly.


Regards,
Xavier,
Linovia.


-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django REST framework 3.4.7 not support RequestsClient

[Xavier Ordoquy]

Hi,

> Le 19 oct. 2016 à 10:31, korea k  a écrit :
> 
> hi,guys.   I read the offical docs through 
> http://www.django-rest-framework.org/api-guide/testing/
> It  say as blew:
> 
> REST framework also includes a client for interacting with your application 
> using the popular Python library, requests.
> 
> This exposes exactly the same interface as if you were using a requests 
> session directly.
> 
> client = RequestsClient()
> 
> response = client.get('http://testserver/users/')
> 
> 
> 
> But I can‘t find the location of RequestsClient。
> 
> It doesn't exist in rest_framwork.test
> 


It looks like it’s there.
https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/test.py#L118
 


Regards,
Xavier,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Hyperlinking to a filtered list

[Xavier Ordoquy]

Hi,

> Le 17 oct. 2016 à 23:23, Brian Stempin  a écrit :
> 
> Hi,
> I'm trying to hyperlink to a filtered list.  Let's say I have these 
> resources:  User and Transaction.  A User has many Transactions, and each 
> Transaction has exactly one User.  Because a User could have hundreds of 
> transactions, I don't want the user to serialize like this:
> 
> [{"id": 1, "transactions": [ hundreds of transaction URLs here ]}]
> 
> but rather like this:
> 
> [{"id": 1, "transactions": "http://server/transactions?user=1"; }]
> 
> This way, the REST client could follow the URL and even apply additional 
> filtering if it so desired.
> 
> Is there an easy way to do this?  I seem to not be having any luck with 
> HyperlinkedRelatedField.
> 
> Thanks,
> Brian

I don’t think you could have an out of the box solution for it.
You need knowledge of the entry point url and the filter name.
The best solution I can think of being to make a property out of a function in 
the User that reverse the entry point url and add the filter yourself.

Regards,
Xavier,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Serializer context with viewsets

[Xavier Ordoquy]

Yes, that's correct.

Xavier,
Linovia.

Le lundi 3 octobre 2016 11:31:17 UTC+2, AJ Ostergaard a écrit :
>
> Ah - so the way to provide additional detail for the serializer is to 
> override get_serializer_context() in the ViewSet and have it return the 
> default context plus the additional custom detail - correct?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tutorial workflow or approach

[Xavier Ordoquy]

Hi Mehmet,

> Le 20 sept. 2016 à 22:04, Mehmet Dogan  a écrit :
> 
> Hello all,
> 
> I am trying to get my feet wet with the DRF and felt the urge to provide a 
> piece of feedback. I found the quickstart pretty helpful, but the 7-step 
> tutorial threw me off. Although I appreciated it more at my 2nd attempt, I 
> still find its flow counter intuitive. It goes from more detailed to less 
> detailed, whereas when you are learning something, you usually go from simple 
> to hard (or from general use to specific/custom usage). It is more like how 
> DRF evolved over time, than a beginner material. 
> 
> Just to illustrate further with an example, I did the quickstart and feel 
> comfortable with ModelViewSet approach, and now want to go one step further 
> and customize it a little, this means going from step 7 of the tutorial to 6, 
> have to read backward! :)
> 
> Possible but hard. Please let me know what you think. 
> 
> Mehmet


Thanks for your feedback, much appreciated.

The tutorial is designed in a way to introduce parts of the framework. Though I 
didn’t wrote it, I consider the current version helps getting how parts are put 
and working together.

The downside of the quick start like approach is that we’ll loose too many 
people before the end.
Most will stop when they get what they want. It is unlikely they would come 
back and complete the tutorial. Then we’ll have complains about things were not 
documented or hard to understand. In other word, they’ll miss the big picture 
of the framework.

The current flow doesn’t get you started quickly but will let you discover the 
various part of the framework. You’ll get the big picture that you won't get 
from the topics themselves. Once you get that big picture, you can pick the 
topic you need to focus on and go further.

I’d be interested in hearing more about alternatives.

Regards,
Xavier,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Not picking up Danish translations

[Xavier Ordoquy]

Hi,

> Le 31 août 2016 à 11:01, Jeppe Vesterbæk  a écrit :
> 
> I'm sending requests with "Accept-Language: da". Translations originating 
> from Django (eg. "This field is required.") and translations in my own apps 
> work. Strings in rest framework always are always returned in english, eg. 
> "This field may not be blank.". Looking into the locale folder of rest 
> framework, I can see both "da" and "da_DK" where "da_DK" contains empty 
> strings only. 
> 
> If I delete the da_DK folder in rest_framework, the Danish translations work.
> 
> I'm not sure how Django / gettext resolves a translation key, but it somehow 
> seems to get confused by the empty string found in da_DK and instead use the 
> key (english base).

Thanks for reporting. Translations seems to be somewhat hard to get right.
Your issue may indicate that Danish translation has been claimed but not 
performed on transiflex.
DRF has a - small - common set of translatable strings with Django. 
Unfortunately in your case, DRF takes precedence over Django.
I though empty string would be considered as non existant by the Django 
translation engine.

The options are:
- we remove the danish translation from transifex
- someone performs the translation (via transiflex)

Regards,
Xavier,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PUT request and updating ManyToMany

[Xavier Ordoquy]

> Le 13 août 2016 à 14:20, Jenna Pullen  a écrit :
> 
> One further question regarding your response. If a PUT request should clear 
> out the existing categories if a single category is posted. How would the 
> user keep his existing catergories if he just wanted to add another category 
> to the existing categories. Would they need to resend all the categories in 
> the PUT request along with the new one? ie http .../api/questions PUT 
> categories:=[all of them again even though he just wants to add a single 
> category to the existing ones already associated]?
> 
> Thank you

The workflow should be to issue a GET, alter the data and sent the PUT. So yes, 
they should send all the related data.

This being said, you could choose an append only policy, but then you should 
make it clear about the behavior and have an alternative way to clear the 
related data.
Note that this is not the usual way users will expect the API to work.

Regards,
Xavier,
Linovia.


> On Saturday, 13 August 2016 12:16:45 UTC+2, Jenna Pullen wrote:
> I have a couple of questions below and would really appreciate some light on 
> the way to handle the situations described below using the REST framework 
> where a user can be posting from a web form where we know that we intend to 
> happen or via a cli where we do no know that the user intends to happen.
> 
> If I have a SerializerClass that has a reference to a m2m (shown below)
> 
> 1. When a PUT request is sent to update the record and no data for the m2m 
> relationship was sent with the request should the update method expect that 
> no data was posted for that m2m so the user intended for them to be removed. 
> Or does the user expect them to be left in place when not posting any data 
> for the m2m? I would think the user expects them to be left in place. But if 
> that is the case, then how would the user signify that he intends for them to 
> be removed on an update? Should that be handled with a delete request or a 
> new resource url be created for this purpose?
> 
> 2. If the user does send data for the m2m relationship in the PUT request ie 
> a list with one item categories=[{"category":"test"}] are they expecting the 
> REST api update method update the relationship to only contain the one 
> element and remove the rest, or are they expecting to keep the existing 
> records and just add the extra relation? 
> 
> So should a PUT request be able to delete m2m relations on that record or 
> should it only be able to ever add to existing relations and a new resource 
> url should be used to remove the m2m relations?
> 
> Example code below.
> 
> Thanks
> 
> 
> class QuestionSerializer(serializers.HyperlinkedModelSerializer):
> class Meta:
> model = Question
> fields = ('pk', 'question', 'user', 'url', "categories")
> 
> categories = CategorySerializer(many=True, required=False)
> user = serializers.ReadOnlyField(source='user.username')
> 
> def update(self, instance, validated_data):
> q = validated_data.get('question', instance.question).strip()
> 
> instance.question = q
> instance.save()
> 
> #1.  If an empty list is passed in from a form or cli or no data at 
> all, does this signify that they should be removed or left in place. If they 
> should be left alone, do we create a new
>#resource url to delete them
>
>  #2.  If 1 category is passed in a list, does that mean the rest of 
> the categories get removed and we just add the new one
># or does it mean we leave the categories in place and add the new one 
> to the existing categories?
> categories = validated_data.get('categories')
> if categories:
> #instance.categories.clear() # should we clear out or not?
> for category in categories:
> c = Category.objects.get(Q(user=self.context['request'].user) 
> | Q(user=None),
>  **category)
> instance.categories.add(c)
> return instance
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ManyToMany validation issue.

[Xavier Ordoquy]

Nested serializers don't work with html forms at the moment. Started to 
work on this is this is still work in progress.

Regards,
Xavier,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PUT request and updating ManyToMany

[Xavier Ordoquy]

Hi,

First thing you should note, it’s not just about ManyToMany relation here but 
rather about nested serializers.


> Le 13 août 2016 à 12:16, Jenna Pullen  a écrit :
> 
> I have a couple of questions below and would really appreciate some light on 
> the way to handle the situations described below using the REST framework 
> where a user can be posting from a web form where we know that we intend to 
> happen or via a cli where we do no know that the user intends to happen.
> 
> If I have a SerializerClass that has a reference to a m2m (shown below)
> 
> 1. When a PUT request is sent to update the record and no data for the m2m 
> relationship was sent with the request should the update method expect that 
> no data was posted for that m2m so the user intended for them to be removed. 
> Or does the user expect them to be left in place when not posting any data 
> for the m2m? I would think the user expects them to be left in place. But if 
> that is the case, then how would the user signify that he intends for them to 
> be removed on an update? Should that be handled with a delete request or a 
> new resource url be created for this purpose?

My usual take on this:
- sending a null value means the field is ignored and thus the related data are 
left as is
- sending an empty list means the related data should be cleared

> 2. If the user does send data for the m2m relationship in the PUT request ie 
> a list with one item categories=[{"category":"test"}] are they expecting the 
> REST api update method update the relationship to only contain the one 
> element and remove the rest, or are they expecting to keep the existing 
> records and just add the extra relation? 

PUT is supposed to replace the old instance by the new. Therefore, it is 
usually assumed that the previous related data will be cleared and that you’ll 
only have test after the request.

> So should a PUT request be able to delete m2m relations on that record or 
> should it only be able to ever add to existing relations and a new resource 
> url should be used to remove the m2m relations?

Usually, it’ll be the former.

Hopes this will help,

Regards,
Xavier,
Linovia.

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.