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

I am seeing a lot of framework specific global functions but don’t know where they come from, such as “view()”, “redirect()” etc etc.

ORM

Again, as mentioned in part 1, since we are creating migration files first, then we won’t be able to define FK relationships directly point to another model. According to the “intermediate quickstart” tutorial, you have to be a bit lower level like:

$table->integer('user_id')->index();

Hang on… Would this create a FK constraint automatically like Django??

Still ORM

Let’s add a few things to this model. First, we will state that the name attribute on the model should be “mass-assignable”. This will allow us to fill the name attribute when using Eloquent’s createmethod:

class Task extends Model{
    protected $fillable = ['name'];
}

Hmm, what? Skimming through the tutorial, so this enables you to do this:

$request->user()->tasks()->create([
        'name' => $request->name,
    ]);

Still ORM – take 2

In Django, when you define a ForeignKey like this

class User(models.Model):
  email = models.EmailField()

class Task(models.Model):
  user = models.ForeignKey(User, related_name="tasks")

You can access the relationship in both ways automatically:

task.user
user.task_set.all()
user.tasks.all() // using optional defined related_name

But in Laravel, it seems you have to define the relationship in each model.

class User extends Authenticatable
{
    // Other Eloquent Properties...

    /**
     * Get all of the tasks for the user.
     */
    public function tasks()
    {
        return $this->hasMany(Task::class);
    }
}

class Task extends Model
{
    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = ['name'];

    /**
     * Get the user that owns the task.
     */
    public function user()
    {
        return $this->belongsTo(User::class);
    }
}

After setting up the quickstart project, I feel the project structure is quite different to Django. In Django a lot of code are organised in “app” domain, but it seems to me that multi-app is not something out-of-the-box in Laravel: https://laracasts.com/discuss/channels/general-discussion/laravel-5-multi-app-or-modular-applications

Instead, it seems the apps in Django is more similar to the “Service Providers” in Laravel.

ORM

While working on the quickstart project in Laravel, it seems to me that Eloquent doesn’t generate initial migratios based on model definition.

In Django, you define the model, then by running “makemigration” CLI command, it will generate initial migration files to create the database table for that model.

According to the quickstart project, it seems to be things work the other way around, you will have to manually create the migration files by running

php artisan make:migration create_tasks_table --create=tasks

And then create the model class by running

php artisan make:model Task

I did a google search “Laravel for Django developers” and got pretty much nothing useful, sure, who would have move back to PHP from Python? I think this only happens in New Zealand.

In the coming series, I will share my journey of learning Laravel, while comparing to Django, hopefully it will help out other Django developers like myself.

I am not a sales person so I don’t know how to sell it, but it’s not hard from a technical perspective to, let’s say consolidate all real estate websites in NZ into a platform.

If we look at all these real estate listings, they basically consisted with 2 models, the “listing” and “agent”. Having those 2 models stores 90% of the information needed. Surely we are not stopping at those 2 models, we will normalise the repetitive fields into models defined such as “location” , “company”(if we e want to have just one installation to serve multiple company websites”, etc etc. I think for implementing this is using Django, creating models is a breeze and using Django Rest Framework serving as APIs.

Slapping on a comprehensive search function using ElasticSearch, easy.

Since now we have a backend and communicating via API calls, then implementing the frontends is rather a freedom of choice for different companies. Lots of options (Django, NodeJS etc etc)

Side note:

These real estate companies will most probably have their own CRM systems, might be a bit of pain the implement the integration and probably having each installation for every company is a better choice.

A colleague of mine mentioned this site http://ccbv.co.uk/ which provides references and information about django class based views.

If you have Order and OrderItem models, your order FK is in OrderItem model, from OrderItem model point of view, it’s Many OrderItem to One Order, in other words ManyToOne. What this implies is you need to have Order records before OrderItem records.

Now, why we need one to many:

What if you have 2 different apps, say Settlement and Payment, which a payment can have multiple settlements, but settlements can only belong to one payment. Logically Payment app is built on top of Settlement app, in other words Settlement app doesn’t need to know about Payment app. But to make the constraint to work, you need to put the Payment foreignkey into the Settlement model (surely this makes sense in DB schema, but not in programming domain), which now Settlement app is required to know about the Payment app.

Not only the dependency is reversed, now you need to have payment record created before settlement record, WTF? Oh certainly you have the payment FK set to nullable, but then you will have an extra step to set the relationship.

Luckily there is a 3rd party package that kind of solve this problem through ManyToMany relationship by adding unique constraint on the right hand column, but unluckily if you ever want to roll back to the normal ManyToManyField, the migration doesn’t remove the additional constraints that introduced by this package. See django ticket.

For relevant information:

http://stackoverflow.com/questions/25635408/django-one-to-many-field-without-reversing-dependency

http://blog.amir.rachum.com/blog/2013/06/15/a-case-for-a-onetomany-relationship-in-django/

The goal is to achieve something like


http://localhost:8000/api/(resource)/
http://localhost:8000/api/v1/(resource)/


plus allowing clients to specify the version in request header (X-Version), here is how we did it.

Structure in side the API app:


├── __init__.py
├── middlewares.py
├── urls.py
├── v1
│ ├── __init__.py
│ ├── account
│ │ ├── __init__.py
│ │ ├── serializers.py
│ │ └── views.py
│ └── urls.py
└── v2
├── __init__.py
├── account
│ ├── __init__.py
│ ├── serializers.py
│ └── views.py
└── urls.py


project urls.py:

url(r'^api/', include('project.api.urls', namespace='api')),

api app level urls.py:

from django.conf.urls import *

urlpatterns = patterns('',
    url(r'', include('project.api.v2.urls', namespace='default')),
    url(r'^v1/', include('project.api.v1.urls', namespace='v1')),
)

version level urls.py

from django.conf.urls import *
from .account import views as account_views
from rest_framework.routers import DefaultRouter

router = DefaultRouter()
router.register('account', account_views.AccountView)
router.register('myaccount', account_views.MyAccountView)
urlpatterns = router.urls

create a middleware to switch to the correct code by changing the path_info, please note there is a caveat that namespace (‘api’) defined in project level urls is not flexible and needs to be known in middleware:

from django.core.urlresolvers import resolve
from django.core.urlresolvers import reverse


class VersionSwitch(object):

def process_request(self, request):
    r = resolve(request.path_info)
    version = request.META.get('HTTP_X_VERSION', False)
    if r.namespace.startswith('api:') and version:
        old_version = r.namespace.split(':')[-1]
        request.path_info = reverse('{}:{}'.format(r.namespace.replace(old_version, version), r.url_name), args=r.args, kwargs=r.kwargs)

Sample url:

curl -H "X-Version: v1" http://your.domain:8000/api/myaccount/

My original answer on stackoverflow.

import datetime
from haystack import indexes   
from cms.models.managers import PageManager
from cms.models.pagemodel import Page
from cms.models.pluginmodel import CMSPlugin


class PageIndex(indexes.SearchIndex, indexes.Indexable):
    text = indexes.CharField(document=True, use_template=False)
    pub_date = indexes.DateTimeField(model_attr='publication_date', null=True)
    login_required = indexes.BooleanField(model_attr='login_required')
    url = indexes.CharField(model_attr='get_absolute_url')
    title = indexes.CharField(model_attr='get_title')

    def prepare(self, obj):    
        self.prepared_data = super(PageIndex, self).prepare(obj)
        plugins = CMSPlugin.objects.filter(placeholder__in=obj.placeholders.all())
        text = ''              
        for plugin in plugins: 
            instance, _ = plugin.get_plugin_instance()
            if hasattr(instance, 'search_fields'):
                text += ''.join(getattr(instance, field) for field in instance.search_fields)
        text += obj.get_meta_description() or u''
        text += obj.get_title() or u''
        text += obj.get_meta_keywords() if hasattr(obj, 'get_meta_keywords') and obj.get_meta_keywords() else u''
        self.prepared_data['text'] = text
        return self.prepared_data       

    def get_model(self):
        return Page

    def index_queryset(self, using=None):
        return Page.objects.published().filter(publisher_is_draft=False).distinct()

when you have a unicode function like this:

def __unicode__(self):
  return "{0}".format(self.field_one)

It is actually returning a ASCII string(which means, it will try to convert field_one to ASCII), if the field_one contains characters outside of ASCII, you will get the problem as above.

Now consider this unicode function:

def __unicode__(self):
      return self.field_one

This works fine, because you are returning unicode string directly, no conversion needed.

Lets revisit the first unicode function, to make it work, you just need to add u to make it a unicode string

def __unicode__(self):
      return u"{0}".format(self.field_one)