Tuesday, February 28, 2017

Re: Advice: django deploy vps error 502

Hello,

502 usually means the backend isn't running. After you finish the test, has the backend stopped running? Does it continue to throw 502s? If that is the case, I'm wildly guessing that processes might be growing and growing in memory and being eventually killed, but I don't really know. Do you have DEBUG = False? Does uwsgi write something in its log? Does the system write something in the syslog?

Regards,

Antonis

Antonis Christofides  http://djangodeployment.com

On 02/28/2017 10:49 PM, carlos wrote:
Hi, all 
i have one vps for one application,

 vps description

16GB RAM
8 core processor
160 GB SSD
6TB Transfer

ok, i am using, uwsgi(2.0.14), nginx(1.10), mysql(5.6 )and ubuntu 16.04 LTS
this site working well when is visited or hits 1k even 6k, but when visited 10k or 12k
raiser error 502,

When I do a test of ab like these command line
ab -k -c 350 -n 20000 mydomain.com/
again raiser the error 502 in almost pages

these are configs all, wsgi, nginx

---- uwsgi script in /etc/uwsgi/app-availabre/website.ini -----

---- nginx conf in /etc/nginx/nginx.conf  ------

----- nginx vhost for my website mydpmain --------

How can I do so that the site does not throw the error?

Are the settings correct?

How can i know the layer support the vps?

In nginx how to stop the ab test, if many people do the test the web site throws the error 502 ngixn

I would appreciate it if someone gave me an idea or advice to configure better when there is high traffic or are doing ab test or another benchmarking test

cheers

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

database update after paypal payment

hello! I am trying to update my database after paypal has received  the payment from customer. The problem is that I don't really know to do it. This is what I am doing now

here is my model

class SubmitDoc(models.Model):
    Student = 'stu'
    Professional = 'Pro'
    
    Status_CHOICES = (
        (Student, 'Stu'),
        (Professional, 'Pro'),
       
    )
    
    firstName = models.CharField(max_length =100)
    lastName = models.CharField(max_length =100)
    email = models.EmailField()
    Stud_status = models.CharField(
        max_length=3,
        choices=Status_CHOICES,
        default=Student,
    )
    uploadDoc = models.FileField(upload_to='documents/%Y/%m/%d/')   
    comment = models.TextField()
    created_on = models.DateTimeField(auto_now_add=True, editable=False)
    paid = models.BooleanField(default=False)
    finished_read = models.BooleanField(default=False)
    read_by = models.CharField(max_length = 100, default="none")

This is my view function to handle the forms that are submitted

def newSubmit(request):
    save= False
    form = SubmitDocForm(request.POST, request.FILES)
    com =0
    compteur=0
    message ="bon"
    solution = ""
    counted=0
    stud = False
    amount_stu = 0.02
    amount_pro = 0.03
    
   
    if form.is_valid():
        submitDoc = SubmitDoc()
        submitDoc.firstName = form.cleaned_data['firstName'] 
        submitDoc.lastName = form.cleaned_data['lastName']
        submitDoc.email = form.cleaned_data['email']
        submitDoc.Stud_status = form.cleaned_data['Stud_status']
        submitDoc.uploadDoc = form.cleaned_data['uploadDoc'] 
#         submitDoc.like = form.cleaned_data["like"]  
        submitDoc.comment = form.cleaned_data['comment']
        submitDoc.save()
        save = True
#         data = request.FILES["uploadDoc"]
        pathy = submitDoc.uploadDoc.path
        solution= get_docx_text(pathy)
        counted = len(solution.split())
        type_of_doc =  form.cleaned_data['Stud_status']
        
        if  form.cleaned_data['Stud_status'] == "on":
            stud = True
            totals = round(counted*0.02, 2)
        else:
            stud = False
            totals = round(counted *0.03, 2)
        
    else:
        form = SubmitDocForm()
         
    return render(request, 'francais/saved.html', locals())

My problem is that I would like to update the database, the "   paid = models.BooleanField(default=False)"  field to true after the payment is received from paypal.

Here is how I redirect the user to paypal for payment:

<form action="https://www.paypal.com/cgi-bin/webscr" method="post">
<input type="hidden" name="cmd" value="_xclick">
<input type="hidden" name="business" value="francaisvitefaite@gmail.com">
<input type="hidden" name="item_name" value="Proofreading">
<input type="hidden" name="currency_code" value="CAD">
<input type="hidden" name="amount" value={{totals}}>
<input type="hidden" name="custom" value="paid">
<input id="id_cancel_return" name="cancel_return" type="hidden" value="http://www.example.com/order/21/">
<input id="id_return_url" name="return" type="hidden" value="http://www.example.com/thank-you">
<input type="submit" class="w3-btn w3-white w3-border w3-border-red w3-round-large" value ="Pay with Paypal" name="submit" alt="Make payments with PayPal - it's fast, free and secure!">
</form>

 
    
Please help me to change the paid field to "True".

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/211bcb0e-23aa-470f-9874-7d9c281398ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Advice: django deploy vps error 502

Hi, all 
i have one vps for one application,

 vps description

16GB RAM
8 core processor
160 GB SSD
6TB Transfer

ok, i am using, uwsgi(2.0.14), nginx(1.10), mysql(5.6 )and ubuntu 16.04 LTS
this site working well when is visited or hits 1k even 6k, but when visited 10k or 12k
raiser error 502,

When I do a test of ab like these command line
ab -k -c 350 -n 20000 mydomain.com/
again raiser the error 502 in almost pages

these are configs all, wsgi, nginx

---- uwsgi script in /etc/uwsgi/app-availabre/website.ini -----

---- nginx conf in /etc/nginx/nginx.conf  ------

----- nginx vhost for my website mydpmain --------

How can I do so that the site does not throw the error?

Are the settings correct?

How can i know the layer support the vps?

In nginx how to stop the ab test, if many people do the test the web site throws the error 502 ngixn

I would appreciate it if someone gave me an idea or advice to configure better when there is high traffic or are doing ab test or another benchmarking test

cheers

--
att.
Carlos Rocha

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

attribute required and error XML

Hi all,
I have  an problem. When I use the django library  form, It create an attribute "required" for an input. But when I look on my explorer (firefox or chrome or IE) i have a XML error.
"XML parsing error: malformed".

this is my code :
"
class LoginForm(forms.Form):
email = forms.EmailField(label='Courriel :')
password = forms.CharField(label='Mot de passe :',
widget = forms.PasswordInput)
def clean(self):
cleaned_data = super (LoginForm,self).clean()
email = cleaned_data.get("email")
password = cleaned_data.get("password")
if email and password:
if password != 'bob' or email != 'bob@bob.fr' :
raise forms.ValidationError("Adresse de courriel ou mot de passe erroné.")
return cleaned_data
"

this is my déclaration for XML and doctype :
"
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr"> "

I can put "required=False" and it's OK, but I want that my input is required (required=True it's not OK)
XML don't accept that required attribute is alone, whithout "= someting".

If someone has had this problem?

Django 1.10
Firefox last update

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

intergate python file to work to a value recover by rest api

Hi
I have a mobility code of 2 points, I have already a map with a marker, I would like to integrate the mobility code (mobility for x and y) to the marker 

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

Re: Handle uncaught exceptions?

Hi, what you need is a middleware with process_exception method. Be sure that it's the last one in MIDDLEWARE setting.


On 28 Feb 2017, at 08:57, Chillar Anand <anand21nanda@gmail.com> wrote:

In staging server, for staff users, I am trying to show actual exception even if DEBUG is False.

I am using this wsgi file for it. However, handle_uncaught_exception method is not getting called?

Any help on how to fix this?

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

Re: What's the best way to create a reusable pagination template?

Yep. My solution is a custom template tag

from django.template.defaulttags import register
from urllib.parse import urlencode

@register.simple_tag(takes_context=True)
def querystringmod(context, *args):
   
"""Modify current querystring:
     {% querystringmod name value [name value [...]] %}
    """

   
if (len(args) % 2) !=0:
        args
.append("")
    request
= context['request']
    current_qs
= request.GET.dict()
    current_qs
.update(dict([ (args[n], args[n+1]) for n in range(0, len(args), 2) ]))
   
return urlencode(current_qs)

in template
<a href="?{% querystringmod "page" page_obj.previous_page_number %}">previous</a>



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

Monday, February 27, 2017

Handle uncaught exceptions?

In staging server, for staff users, I am trying to show actual exception even if DEBUG is False.

I am using this wsgi file for it. However, handle_uncaught_exception method is not getting called?

Any help on how to fix this?

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

finding intersection of linestring and list of polygon

Hi,

  I'm not sure if this is the right place for this or not - let me know if I should post somewhere else (GEOS mailing list).

  I have a large list (1000's) of polygons (django.contrib.gis.geos.Polygon), some of which overlap.  What is the most efficient way to find which polygons intersect with a LineString?

  I would have thought that turning the list of Polygon's into a MultiPolygon, then calling MultiPolygon.intersection with the line segment would give me the polygon that the line segment intersected on.  This does work, but it just returns the line segment itself.  I'm trying to go the other way.

  I was hoping for a faster mechanism than just filter'ing over the original polygon list and calling intersect's on it.

  I'm having to use Django 1.6.7 if that matters.

Thanks,
Taz

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

Multiple Databases --- Migrations

I am using 2 postgres databases in my django app.



     'newpostgre': {
       'ENGINE': 'django.db.backends.postgresql_psycopg2',
       'NAME': 'new_postgre2',
       'USER': 'tester',
       'PASSWORD': 'password',
       'HOST': 'localhost',
       'PORT': '',
       },
      

     'newpostgre2': {
          'ENGINE': 'django.db.backends.postgresql_psycopg2',
          'NAME': 'new_postgre3',
          'USER': 'tester',
          'PASSWORD': 'password',
          'HOST': 'localhost',
          'PORT': '',
     },


I have a very simple model

    

     class Check1(models.Model):
          title = models.CharField(max_length=100)


I had run

    

    python manage.py migrate --database=newpostgre
    python manage.py migrate --database=newpostgre2


when I open my new_postgre2(for newpostgre) database in postgre, I can see my Check1 table there.


But in my new_postgre3(for newpostgre2) database in postgre, no Check1 table is there, only those initial migrations are there.


Why I can't see my table in new_postgre3 when migrations have been successfully made? Or is there any rule that model can be migrated to only 1 database ?

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

Re: Connecting to a database with logged in user credentials

Thank you Melvyn. For now it's the best option we've found.


W dniu czwartek, 23 lutego 2017 18:38:14 UTC+1 użytkownik Melvyn Sopacua napisał:
Hi Konrad,

On Thursday 23 February 2017 02:54:22 konrad....@uni.lodz.pl wrote:


> After starting the project, we've realised that db routing is limited
> to the set of db connections that are statically described in django
> settings.

Just a few minutes before your post, a link was posted:
https://github.com/ambitioninc/django-dynamic-db-router

So no, they're not static. This package may not suit your needs, but
it's mechanism with a custom router should help you along.

--
Melvyn Sopacua

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

Re: Flattening model relationships (in APIs)

Wanna read something interesting? Look at http://t-code.pl/blog/2016/02/rest-misconceptions-0/
You will realize how many "antipatterns" are propagated in turorials on our World Wide Web, and where they're already implemented.
 

On Monday, February 27, 2017 at 2:52:46 PM UTC+1, Ankush Thakur wrote:
Marcin, that's exactly where I'm stuck! I know endpoints should never be 1:1 serialization of models, but I just don't know how to do that. I mean, I've been able to create endpoints like "/customers/1/payments/" where I use model relationships to generate JSON structures where Customer contains a Payments array field. My Address endpoint seems to be an oddity, as API consumers don't expect the city to contain state and the state to contain country as a JSON structure. How can I add these to the top-level Address entity directly while serialization? That's where I have no answers. Would it be possible for you to point me towards some article that does that? Thanks in advance!

Regards,
Ankush

On Monday, February 27, 2017 at 3:41:49 AM UTC+5:30, marcin....@gmail.com wrote:


On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote:
If the relationship chain was even deeper, there would be even more nesting, which I feel isn't great for API consumers. What is the best practice here to put state and country at the same level as the city? 

Just follow REST design. 
Forget django models, think about encapsulation.
Think about representation of a resource, not about serializing a model(s).
Make semantic representations, as good as possible.

You are not forced to do any nested nasty things. This has nothing to do with REST api.
You may feel that DRF is limiting you. You'll be on a good path, if so. :)

Good luck!
Marcin

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/1fe8f663-8d38-41af-87e8-8a06bf2301d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Flattening model relationships (in APIs)



On Monday, February 27, 2017 at 3:38:34 PM UTC+1, Xavier Ordoquy wrote:

The more strict RESTfull way would be to use the several entry points and use hyperlinks on them (though it would add some extra requests).


This is just about representation. Nobody forces you to do such things. 
You may include more or less data, require linking or not - it does not matter. Client should just *know* what to do - read *something* or *follow link* to read *something*. 
Everything is about semantic, not about a structure.

The most important is hyperlinking, hypermedia and the state transfer. 

Marcin

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/374d2df8-23b1-4bd8-9a22-9203d007d7b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Flattening model relationships (in APIs)



On Monday, February 27, 2017 at 3:30:11 PM UTC+1, Ankush Thakur wrote:
I guess this is the library in question: https://github.com/marcinn/restosaur (took some effort to find it!). Thanks, if I decide to stick with the API-first approach, I'll use it. Either way, I've bookmarked it for future use. :-)


Yes. I'm not annoucing it, because of entering early beta stage. But on the other side I've decided to use it in production starting from early alphas, and it just works.
This is a thin glue between web framework and your REST(-ful, -ish, plain http, what you want) services, so there is no big issues at all.
Last commits gave me possibility to run api top on a Flask framework, so it is fun. 
Still alpha-beta, so I can't give you any guarantee of satisfaction ;)

DRF has mature community, support, etc. Use it if it will work for you. Otherwise you're welcome to Restosaur community. 

BR,
Marcin

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

Re: Flattening model relationships (in APIs)

Quick question. How will you handle the fields updates ?
Like, what if you get an city_name="Bombay" and city_code="DEL" ?

If you can set them as read-only, then using the source argument is the way to go.
Alternatively, you can define a non model serializer and flatten the data before hand.
You can also decide to drop the serializers and pass a Python structure directly though you would have some work for the validation.

The more strict RESTfull way would be to use the several entry points and use hyperlinks on them (though it would add some extra requests).

You have a couple of options opened to you.
Remember that Django REST framework is no silver bullet.
You should think about how you want to represent your resources first and then write the associated code.
Also remember that easy isn't the same as simple. The framework targets the latter.

Regards,
Xavier.

Le mardi 21 février 2017 20:13:25 UTC+1, Ankush Thakur a écrit :
I'm using DRF for an API. My problem is that I defined my postal address like this (breaking it up into City, State, Country):

class Country(models.Model):    
    class Meta:
        db_table = 'countries'

    name = models.TextField()
    code = models.TextField(unique=True)

class State(models.Model):    
    class Meta:
        db_table = 'states'

    name = models.TextField()
    code = models.TextField(unique=True)
    country = models.ForeignKey('Country', on_delete=models.CASCADE)


class City(models.Model):    
    class Meta:
        db_table = 'cities'

    name = models.TextField()
    code = models.TextField(unique=True)
    state = models.ForeignKey('State', on_delete=models.CASCADE)

class Address(models.Model):
    class Meta:
        db_table = 'addresses'
    
    building_no = models.TextField()
    street = models.TextField(null=True)
    locality = models.TextField(null=True)
    landmark = models.TextField(null=True)
    pincode = models.TextField(null=True)
    latitude = models.DecimalField(max_digits=9, decimal_places=6, null=True)
    longitude = models.DecimalField(max_digits=9, decimal_places=6, null=True)
    city = models.ForeignKey('City', on_delete=models.CASCADE)

Now, in my system, a venue has an address, and so the serializes are defined like this:

class VenueSerializer(serializers.ModelSerializer):
    address = AddressSerializer()
    offerings = OfferingSerializer(many=True)

    class Meta:
        model = Venue
        fields = ['id', 'name', 'price_per_day', 'status', 'offerings', 'address', 'photos']

which leads us to:

class AddressSerializer(serializers.ModelSerializer):
    city = CitySerializer()

    class Meta:
        model = Address
        fields = ['id', 'building_no', 'street', 'locality', 'landmark', 'pincode', 'latitude', 'longitude', 'city']

which leads us to:

class CitySerializer(serializers.ModelSerializer):
    state = StateSerializer()

    class Meta:
        model = City
        fields = ['id', 'name', 'code', 'state']

which leads us to:

class StateSerializer(serializers.ModelSerializer):
    country = CountrySerializer()

    class Meta:
        model = State
        fields = ['id', 'name', 'code', 'country']

which finally leads to:

class CountrySerializer(serializers.ModelSerializer):
    class Meta:
        model = Country
        fields = ['id', 'name', 'code']

and when this gets serialized, the address is given in the following format:

 "address": {
      "id": 2,
      "building_no": "11",
      "street": "Another Street",
      "locality": "",
      "landmark": "Fortis Hospital",
      "pincode": "201003",
      "latitude": "28.632778",
      "longitude": "77.219722",
      "city": {
        "id": 1,
        "name": "Delhi",
        "code": "DEL",
        "state": {
          "id": 1,
          "name": "Delhi",
          "code": "DEL",
          "country": {
            "id": 1,
            "name": "India",
            "code": "IN"
          }
        }
      }
    }

So there's a hell lot of nesting from city to state to country. If the relationship chain was even deeper, there would be even more nesting, which I feel isn't great for API consumers. What is the best practice here to put state and country at the same level as the city? I think this will also complicate the logic while POSTing data, so I'm interested in knowing about that as well.

I'm sorry if there is too much code, but I couldn't think of a better way to convey the situation than actually post everything.


Regards,
Ankush Thakur

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

Re: Flattening model relationships (in APIs)

I guess this is the library in question: https://github.com/marcinn/restosaur (took some effort to find it!). Thanks, if I decide to stick with the API-first approach, I'll use it. Either way, I've bookmarked it for future use. :-)


Regards,
Ankush Thakur

On Mon, Feb 27, 2017 at 7:53 PM, <marcin.j.nowak@gmail.com> wrote:
I was limited by DRF long days ago and I realized that it is not following REST architecutre. It does good job in automation in exposing models over http, but everything else is way complicated.
But there were no problem mix both tools in one project. DRF was for "80%" of work and my lib for the rest. Downsides? Two libs used to get the job done.

Maybe try using DRF's @api_view decorator for function views, and return a pure and manually "flattened" dict?

M.


On Monday, February 27, 2017 at 3:17:35 PM UTC+1, Ankush Thakur wrote:
Hmmm. That's not an answer I wanted to hear, really, but I like it. I'm myself finding DRF too restrictive once you are past the effort-saving magic. Thank you. I might give it up as it's still early days in the project.


Regards,
Ankush Thakur

On Mon, Feb 27, 2017 at 7:43 PM, <marcin....@gmail.com> wrote:
I'm not sure you want to read my answer, really...  I've finally stopped using DRF and wrote own library which is focused on resources, linking and representations.
I think you can do some customization in DRF, probably you ca declare custom serializer class, but this is a hard way, IMO.

I like simple things, so with my lib I can just do something like that:

payments = api.resource('/payments/')
customer = api.resource('/customers/:pk')


@payments.representation
def payment_as_json(payment, ctx):
    return {
        'customer_address': payment.customer.address,
        'customer_url': ctx.link_to(customer, pk=payment.customer_id), # link resources
        'value': payment.value,  # write here
        'and_so_on': True,  # what do you want
    }

Yes, it does not validate automatically and this example is not restful, but you may follow semantic structures like jsonld without any limitation, and apply validation in a controller:

@payments.post(accept='application/json')
def add_payment(ctx):
    form = PaymentForm(data=ctx.body)
    form.is_valid() and form.save(0
    [...]

Where PaymentForm may be a typical Django Form or ModelForm, or even a Colander Schema. 
There is more code to write, but implementation is more explitic.

PEP20: Explicit is better than implicit. Simple is better than complex. Flat is better than nested. Readability counts.  And so on...

BR,
Marcin



On Monday, February 27, 2017 at 2:52:46 PM UTC+1, Ankush Thakur wrote:
Marcin, that's exactly where I'm stuck! I know endpoints should never be 1:1 serialization of models, but I just don't know how to do that. I mean, I've been able to create endpoints like "/customers/1/payments/" where I use model relationships to generate JSON structures where Customer contains a Payments array field. My Address endpoint seems to be an oddity, as API consumers don't expect the city to contain state and the state to contain country as a JSON structure. How can I add these to the top-level Address entity directly while serialization? That's where I have no answers. Would it be possible for you to point me towards some article that does that? Thanks in advance!

Regards,
Ankush

On Monday, February 27, 2017 at 3:41:49 AM UTC+5:30, marcin....@gmail.com wrote:


On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote:
If the relationship chain was even deeper, there would be even more nesting, which I feel isn't great for API consumers. What is the best practice here to put state and country at the same level as the city? 

Just follow REST design. 
Forget django models, think about encapsulation.
Think about representation of a resource, not about serializing a model(s).
Make semantic representations, as good as possible.

You are not forced to do any nested nasty things. This has nothing to do with REST api.
You may feel that DRF is limiting you. You'll be on a good path, if so. :)

Good luck!
Marcin

--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/ttoJbZJOBnU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/a0b23023-8a5c-4257-ad6d-d72639f85925%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/ttoJbZJOBnU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/8dbe0176-7fcd-4736-a0ba-78aee3408ac1%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

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

Re: Flattening model relationships (in APIs)

I was limited by DRF long days ago and I realized that it is not following REST architecutre. It does good job in automation in exposing models over http, but everything else is way complicated.
But there were no problem mix both tools in one project. DRF was for "80%" of work and my lib for the rest. Downsides? Two libs used to get the job done.

Maybe try using DRF's @api_view decorator for function views, and return a pure and manually "flattened" dict?

M.


On Monday, February 27, 2017 at 3:17:35 PM UTC+1, Ankush Thakur wrote:
Hmmm. That's not an answer I wanted to hear, really, but I like it. I'm myself finding DRF too restrictive once you are past the effort-saving magic. Thank you. I might give it up as it's still early days in the project.


Regards,
Ankush Thakur

On Mon, Feb 27, 2017 at 7:43 PM, <marcin....@gmail.com> wrote:
I'm not sure you want to read my answer, really...  I've finally stopped using DRF and wrote own library which is focused on resources, linking and representations.
I think you can do some customization in DRF, probably you ca declare custom serializer class, but this is a hard way, IMO.

I like simple things, so with my lib I can just do something like that:

payments = api.resource('/payments/')
customer = api.resource('/customers/:pk')


@payments.representation
def payment_as_json(payment, ctx):
    return {
        'customer_address': payment.customer.address,
        'customer_url': ctx.link_to(customer, pk=payment.customer_id), # link resources
        'value': payment.value,  # write here
        'and_so_on': True,  # what do you want
    }

Yes, it does not validate automatically and this example is not restful, but you may follow semantic structures like jsonld without any limitation, and apply validation in a controller:

@payments.post(accept='application/json')
def add_payment(ctx):
    form = PaymentForm(data=ctx.body)
    form.is_valid() and form.save(0
    [...]

Where PaymentForm may be a typical Django Form or ModelForm, or even a Colander Schema. 
There is more code to write, but implementation is more explitic.

PEP20: Explicit is better than implicit. Simple is better than complex. Flat is better than nested. Readability counts.  And so on...

BR,
Marcin



On Monday, February 27, 2017 at 2:52:46 PM UTC+1, Ankush Thakur wrote:
Marcin, that's exactly where I'm stuck! I know endpoints should never be 1:1 serialization of models, but I just don't know how to do that. I mean, I've been able to create endpoints like "/customers/1/payments/" where I use model relationships to generate JSON structures where Customer contains a Payments array field. My Address endpoint seems to be an oddity, as API consumers don't expect the city to contain state and the state to contain country as a JSON structure. How can I add these to the top-level Address entity directly while serialization? That's where I have no answers. Would it be possible for you to point me towards some article that does that? Thanks in advance!

Regards,
Ankush

On Monday, February 27, 2017 at 3:41:49 AM UTC+5:30, marcin....@gmail.com wrote:


On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote:
If the relationship chain was even deeper, there would be even more nesting, which I feel isn't great for API consumers. What is the best practice here to put state and country at the same level as the city? 

Just follow REST design. 
Forget django models, think about encapsulation.
Think about representation of a resource, not about serializing a model(s).
Make semantic representations, as good as possible.

You are not forced to do any nested nasty things. This has nothing to do with REST api.
You may feel that DRF is limiting you. You'll be on a good path, if so. :)

Good luck!
Marcin

--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/ttoJbZJOBnU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/a0b23023-8a5c-4257-ad6d-d72639f85925%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

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

Re: Flattening model relationships (in APIs)

Hmmm. That's not an answer I wanted to hear, really, but I like it. I'm myself finding DRF too restrictive once you are past the effort-saving magic. Thank you. I might give it up as it's still early days in the project.


Regards,
Ankush Thakur

On Mon, Feb 27, 2017 at 7:43 PM, <marcin.j.nowak@gmail.com> wrote:
I'm not sure you want to read my answer, really...  I've finally stopped using DRF and wrote own library which is focused on resources, linking and representations.
I think you can do some customization in DRF, probably you ca declare custom serializer class, but this is a hard way, IMO.

I like simple things, so with my lib I can just do something like that:

payments = api.resource('/payments/')
customer = api.resource('/customers/:pk')


@payments.representation
def payment_as_json(payment, ctx):
    return {
        'customer_address': payment.customer.address,
        'customer_url': ctx.link_to(customer, pk=payment.customer_id), # link resources
        'value': payment.value,  # write here
        'and_so_on': True,  # what do you want
    }

Yes, it does not validate automatically and this example is not restful, but you may follow semantic structures like jsonld without any limitation, and apply validation in a controller:

@payments.post(accept='application/json')
def add_payment(ctx):
    form = PaymentForm(data=ctx.body)
    form.is_valid() and form.save(0
    [...]

Where PaymentForm may be a typical Django Form or ModelForm, or even a Colander Schema. 
There is more code to write, but implementation is more explitic.

PEP20: Explicit is better than implicit. Simple is better than complex. Flat is better than nested. Readability counts.  And so on...

BR,
Marcin



On Monday, February 27, 2017 at 2:52:46 PM UTC+1, Ankush Thakur wrote:
Marcin, that's exactly where I'm stuck! I know endpoints should never be 1:1 serialization of models, but I just don't know how to do that. I mean, I've been able to create endpoints like "/customers/1/payments/" where I use model relationships to generate JSON structures where Customer contains a Payments array field. My Address endpoint seems to be an oddity, as API consumers don't expect the city to contain state and the state to contain country as a JSON structure. How can I add these to the top-level Address entity directly while serialization? That's where I have no answers. Would it be possible for you to point me towards some article that does that? Thanks in advance!

Regards,
Ankush

On Monday, February 27, 2017 at 3:41:49 AM UTC+5:30, marcin....@gmail.com wrote:


On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote:
If the relationship chain was even deeper, there would be even more nesting, which I feel isn't great for API consumers. What is the best practice here to put state and country at the same level as the city? 

Just follow REST design. 
Forget django models, think about encapsulation.
Think about representation of a resource, not about serializing a model(s).
Make semantic representations, as good as possible.

You are not forced to do any nested nasty things. This has nothing to do with REST api.
You may feel that DRF is limiting you. You'll be on a good path, if so. :)

Good luck!
Marcin

--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/ttoJbZJOBnU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/a0b23023-8a5c-4257-ad6d-d72639f85925%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

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

Re: Flattening model relationships (in APIs)

I'm not sure you want to read my answer, really...  I've finally stopped using DRF and wrote own library which is focused on resources, linking and representations.
I think you can do some customization in DRF, probably you ca declare custom serializer class, but this is a hard way, IMO.

I like simple things, so with my lib I can just do something like that:

payments = api.resource('/payments/')
customer = api.resource('/customers/:pk')


@payments.representation
def payment_as_json(payment, ctx):
    return {
        'customer_address': payment.customer.address,
        'customer_url': ctx.link_to(customer, pk=payment.customer_id), # link resources
        'value': payment.value,  # write here
        'and_so_on': True,  # what do you want
    }

Yes, it does not validate automatically and this example is not restful, but you may follow semantic structures like jsonld without any limitation, and apply validation in a controller:

@payments.post(accept='application/json')
def add_payment(ctx):
    form = PaymentForm(data=ctx.body)
    form.is_valid() and form.save(0
    [...]

Where PaymentForm may be a typical Django Form or ModelForm, or even a Colander Schema. 
There is more code to write, but implementation is more explitic.

PEP20: Explicit is better than implicit. Simple is better than complex. Flat is better than nested. Readability counts.  And so on...

BR,
Marcin



On Monday, February 27, 2017 at 2:52:46 PM UTC+1, Ankush Thakur wrote:
Marcin, that's exactly where I'm stuck! I know endpoints should never be 1:1 serialization of models, but I just don't know how to do that. I mean, I've been able to create endpoints like "/customers/1/payments/" where I use model relationships to generate JSON structures where Customer contains a Payments array field. My Address endpoint seems to be an oddity, as API consumers don't expect the city to contain state and the state to contain country as a JSON structure. How can I add these to the top-level Address entity directly while serialization? That's where I have no answers. Would it be possible for you to point me towards some article that does that? Thanks in advance!

Regards,
Ankush

On Monday, February 27, 2017 at 3:41:49 AM UTC+5:30, marcin....@gmail.com wrote:


On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote:
If the relationship chain was even deeper, there would be even more nesting, which I feel isn't great for API consumers. What is the best practice here to put state and country at the same level as the city? 

Just follow REST design. 
Forget django models, think about encapsulation.
Think about representation of a resource, not about serializing a model(s).
Make semantic representations, as good as possible.

You are not forced to do any nested nasty things. This has nothing to do with REST api.
You may feel that DRF is limiting you. You'll be on a good path, if so. :)

Good luck!
Marcin

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

Re: Flattening model relationships (in APIs)

Marcin, that's exactly where I'm stuck! I know endpoints should never be 1:1 serialization of models, but I just don't know how to do that. I mean, I've been able to create endpoints like "/customers/1/payments/" where I use model relationships to generate JSON structures where Customer contains a Payments array field. My Address endpoint seems to be an oddity, as API consumers don't expect the city to contain state and the state to contain country as a JSON structure. How can I add these to the top-level Address entity directly while serialization? That's where I have no answers. Would it be possible for you to point me towards some article that does that? Thanks in advance!

Regards,
Ankush

On Monday, February 27, 2017 at 3:41:49 AM UTC+5:30, marcin....@gmail.com wrote:


On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote:
If the relationship chain was even deeper, there would be even more nesting, which I feel isn't great for API consumers. What is the best practice here to put state and country at the same level as the city? 

Just follow REST design. 
Forget django models, think about encapsulation.
Think about representation of a resource, not about serializing a model(s).
Make semantic representations, as good as possible.

You are not forced to do any nested nasty things. This has nothing to do with REST api.
You may feel that DRF is limiting you. You'll be on a good path, if so. :)

Good luck!
Marcin

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/70189b7c-69db-4b3a-9c3e-935121b76ea9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.