I remember I blogged about Laravel back in 2016 (time flies!), and reading them again, I am surprised that what I thought back in 2016 still applies today.

Today I am going to talk about some black magic I’ve encountered writing a test blog project. The bit that filling out the blog form and validating the data. Normally, when a form is posted to an URL, the controller validates the form data and throws validation exceptions if form is not validated, then the controller can redirect the browser back to the form along some error data to be displayed on the form. In Laravel, the redirecting back to the form is automatically done for you and somehow the view magically has the ‘errors’ variable in context.

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.67qnsecr5

My preference is to keep all reusable templates in a partials folder, and place the pagination template in there.

{% if is_paginated %}
<nav>
    <ul class="pagination">
    {% for page_num in paginator.page_range %}
        {% if page_num == page_obj.number %}
          <li class="active"><a href="#">{{ page_num }}</a></li>
        {% else %}
        <li><a href="{% url urlname page_num %}?{{ request.GET.urlencode }}">{{ page_num }}</a></li>
        {% endif %}
    {% endfor %}
    </ul>
</nav>
{% endif %}

The pagination template is switched by the ListView populated context var is_paginated, also makes use of urlname variable to construct the page links.

Then in each list view template to include the pagination:

{% include 'partials/pagination.html' with urlname='quick-admin:listing-job-list' %}

https://github.com/variable/django-rest-framework-queryset 

I think I will just share my working sample code here to save someone’s time

import requests

# local file
with open('image.jpg', 'rb') as file:
    resp = requests.post('http://localhost:8888/image', data=file.read())
    url = resp.headers['Location']

# remote file
remote_resp = requests.get(image_url, stream=True)
resp = requests.post('http://localhost:8888/image', data=remote_resp.content)
url = resp.headers['Location']

from .your_module import unused_stuff  # noqa

Peace.

from django.db import connections
class Receiver(PolymorphicModel):
    ...

class Database(Receiver):
    name = models.CharField(max_length=255)
    def get_data_source(self):
        return connections[name]

Then the feed model:

class Feed(models.Model):
    receiver = models.ForeignKey('Receiver')

    def get_data_source(self):
        return self.receiver.get_real_instance().get_data_source()

Then run this feed in trivial code:

import threading

function transform_listing(feed):
    cursor = feed.get_data_source().cursor()
    ....

feed = Feed.objects.create(receiver=Database.objects.create(name='legacy'))

for i in range(100):
    th = threading.Thread(transform_listing, [feed])
    th.start()

And you will quickly notice the threads complaining

Too many connections

What it’s happening is Django will create a new connection per thread when you access the ORM, and connections are left open even the threads are terminated, in this case the culprit is

def get_data_source(self):
        return self.receiver.get_real_instance().get_data_source()

So in this case, simply refactor the code to close the connection before return:

from django.db import connection
...

    def get_data_source(self):
        result = self.receiver.get_real_instance().get_data_source()
        connection.close()
        return result

Stateless bean in client:

public void work(){
    bean.work1();   // this uses instance 1 in App Server
    ...
    bean.work2();   // this can be instance 2 in App Server
}

Stateful bean in client:

public void work(){
    bean.add_item(item); // this uses instance 1 in App Server
    ....
    bean.checkout();     // this uses instance 1 in App Server
}

• A stateless session bean, should not store a state in the bean instance, in order words, it’s class members should not be assigned by external values.
• A stateful session bean, maintains it’s state until it’s “flushed”, a bean method that is annotated by “@Remove”

def process(request):
    value = request.GET.get('name')
    work(value)

process(request)

The above example has 2 problems:
1. This will become a nightmare to write unit tests on this function, now you need to mock the request object to contain the attribute GET which is a dictionary has a key ‘name’
2. Person reading the code has to spend the effort of what other usage of “request” in the function.

The proper way is to accept a parameter as shallow as possible, in this case, a string

def process(value):
    work(value)

process(request.GET.get('value'))

The above example has 2 advantages:
1. Easy to write unit tests, all you need now is pass in a string
2. The person reading the calling statement knows a string is passed in, no other values are involved.