Fetch the submitter with a join and get all the images and tags in one
query each. This reduces the total query count for loading 50 pins from
304 to 158.
See issue #85.
\d allows numbers from other digit systems, so urls like: http://demo.getpinry.com/१७/ are possible. This could lead to some nasty security issues in the future (ie. if you try to use pin number without using `int(...)`).
Too lax unique constraints for Thumbnail coped with "on demand" thumbnail
generation may leave database in inconsistent state where two thumbnail for
the same size are saved. We should be able to prevent that from happening
by generating all thumbnails when we save the image. Should fix#24, but
I can't figure out a way to actually test it.
We weren't checking if the Pin submitter is the logged user which made it possible
to pass any submitter to the Pin resource create call. Fix it, and make the submitter
optional.
It's part of the issue #20 (weird path on Windows). Django File class used
a full file path which resulted in path like C:\Example\pinry\static\C:\... which
is obviously invalid.
It is a milestone of sort, from now on we're commited to write
correct two-way migrations for our code. It's one of the last
things to be done before an official v1.0 release.
This commit is a foundation upon a more robust image fetching code
will be built in the future, and it already fixes at least one weird
issue I've seen.
Factory Boy provides us with a better way of populating complicated
fields (like M2M relations) than overriding _prepare class method,
so we should be using them.
There has been issues when running a full test suite (for pinry and
the entire Django stack), and test fixtures are hard to maintain anyway,
so rewrite tests to use a Model mocker library (Factory Boy) to populate
database.
"origin" is an optional field that stores the URI for the site
that the image has been saved from, it's going to be used only from
bookmarklet. Fixes#63
