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_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_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_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: [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>.
>>>> For more options, visit https://groups.goo

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: 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 <hihn.rai...@gmail.com> 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 <gprostm...@gmail.com> 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 <xordo...@linovia.com> 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 <cynthia.sim...@financeplan.biz 
>> <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 <leo.tour...@gmail.com> 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 <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 <leo.t...@gmail.com <>> 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 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 <leo.tour...@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 <leo.t...@gmail.com <>> 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 <joecze...@gmail.com> 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 <joec...@ <>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: 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 <ivlevdenis...@gmail.com> 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: 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 <py5...@gmail.com> 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: 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 <priyanka.t...@gmail.com> 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 <matthew.le...@gmail.com> 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 <priyanka.t...@gmail.com> 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 <priyanka.t...@gmail.com> 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: [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: 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 <daiya...@gmail.com> 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: Writing to Nested ModelSerializer

[Xavier Ordoquy]

ect, 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: 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 <solsol9...@gmail.com> 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 <solsol9...@gmail.com> 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 <ngu.anto...@gmail.com> 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>.
> <Sélection_001.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: 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 <solsol9...@gmail.com> 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: 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 <mas...@gmail.com> 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 <xordo...@linovia.com 
> <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 <mas...@gmail.com 
>> <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: 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 <wdthi...@gmail.com 
> <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]

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 <bwanama...@gmail.com> 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 <mashia...@gmail.com> 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 <kan381221...@gmail.com> 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: 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: 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: 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: using DRF with something other than models?

[Xavier Ordoquy]

Hi,

You may also want to look at 
https://medium.com/django-rest-framework/django-rest-framework-viewset-when-you-don-t-have-a-model-335a0490ba6f
It explains how to use a Viewset without models.

Regards,
Xavier,
Linovia.


> Le 21 juin 2016 à 04:25, 'Abraham Varricatt' via Django REST framework 
>  a écrit :
> 
> Hello,
> 
> Is it possible to use Django Rest Framework (DRF) for something other than 
> models? Here's a trivial example,
> 
> To make an API end point which returns the current server time (in JSON 
> format, eg: {"current_time": "XYZ"}). It can accept a string to indicate 
> timezone, and must accept both GET and POST.
> 
> I can figure out how to do the above without DRF using regular Django urls 
> and views. What I can't figure out is how to use DRF for the same.
> 
> From the docs, it looks best to use routers when making a DRF end-point. 
> Which means I need a structure like this,
> 
> urls.py <-> router <-> Viewset <-> Serializer
> 
> But as I understand Serilizers ( 
> http://www.django-rest-framework.org/api-guide/serializers/ ), they can only 
> be used for complex models or querysets - which is not what I need.
> 
> I feel like I'm mis-understanding something about DRF. Help please?
> 
> Puzzled,
> Abraham V.
> 
> 
> --
> 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 using GPGMail

Re: Handling of nested form data with a writable nested serializer

[Xavier Ordoquy]

Hi Daniel

> Le 5 juin 2016 à 10:30, Daniel Haggard  a écrit :
> 
> Hi folks,
> 
> I had this issue recently where I had a writeable serializer nesting User 
> info under the key 'owner', that was passing validation (because it contained 
> the owner related data) but then removing the entire owner field from the 
> validated data.  This would get passed up to my update method which would 
> hang because it was expecting to find owner data to play with.  This was 
> happening when I was using FormData objects on the client side, and it was 
> perplexing because it wasn't happening if I used json instead.
> 
> Turns out it was caused by get_value() method on the nested serializer which 
> would call the utils.html.parse_html_dict function when it gets a QueryDict 
> objects (as it does when it handles FormData).  This is turn does a regex 
> match between the submitted keys in the FormData and the field names.  If it 
> finds no match between a key and a field it returns empty.  The regex 
> specifies that to match,  the key which is used to represent nested data must 
> include a full_stop character.  So in my case the keys of nested data should 
> look something like:  'owner.email'.  But because all I had included was a 
> key: 'owner'.  The regex never found a match.
> 
> No big deal - as I now know what I should be doing.  But I'm just wondering 
> if this convention for nested data in FormData objects is documented in the 
> api docs?  I've spent quite a lot of time looking for it - but couldn't find 
> anything.  But apologies if I missed it.  Or is this just a standard 
> convention for getting around the limits of form nesting in html5?  My 
> googling on that topic is that lots of folk do lots of very different things.
> 
> Also - I'm wondering if it's ideal that the serializer should be able to pass 
> validation in this instance?
> 
> Thanks for your time :)


At the moment, nested writable nested forms are not supposed to work. There is 
possibly an exception for a direct foreign key relation.
I’m currently working on making writable nested forms working in all the cases.
I’ll give some thought about adding documentation on that part.

I’m not sure I correctly understood your issue.
Browsable API should have the correct names right out of the box. It’ll also 
display a comment about nested forms not working if it doesn’t.

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.