Support lookups on objects_represented that aren't PositiveIntegerFields named "id" about django-papertrail HOT 3 CLOSED

We might want to reconsider this, @chazeah:

1. It requires some ugly hacks (please see https://github.com/FundersClub/django-papertrail/compare/feature/varchar-related-ids). Seems to work fine with those hacks (tests pass on Django 1.8/1.9), but who knows if it'll come bite us in the ass at a later point.
2. I don't know if these impose any significant performance penalties or not - I can look into it, but there's a chance they do.
3. Since one of the hack uses Func it means we'll need to drop Django1.7 support (fine by me).

Other than our internal apps which (made the mistake, in my opinion - not only it surfaces issues such as this, but it is also significantly more expensive to store/compare) of using non-standard primary keys, we haven't seen a demand for this.

from django-papertrail.

As the primary maintainer of papertrail, I look to you for a strong opinion on whether this change introduces unnecessary complexity and overhead. It definitely complicates things, and for only a small upside. Defer to you on path forward.

from django-papertrail.

Going to skip this for now. If a justified need arises in the future I'll re-evaluate. I don't feel like such a need has been demonstrated at this point.

from django-papertrail.