* Oracle's connector does not work with Django 1.7
* MySQLdb has no Python 3 support
* The Python 3 support fork of MySQLdb doesn't support Python 2
So, good fun. But more googling turned up PyMySQL, which works a treat.
No idea why that isn't documented given the current poor state of
database adapters for MySQL.
Registering receivers is a tricky business pre-Django 1.7 as they get
registered at the same time when models get registered, but require the
sending model to already be in the app cache. It's surprising we don't
see more issues!
Recommendations:
* Avoid calls to get_model in modules that get called during app init at
all cost
* Don't use get_model in your own code. Just import directly.
* Switch to Django 1.7 :)
This commit probably fixes the issue in #1205. But get_model calls to
fetch the category, product image and stock record will all fail,
because receivers listen to their signals.
This commit also moves the catalogue receiver into it's own receivers
module, because that's how we do it elsewhere. That won't make a
difference to the issues though.
Correct amount calculation when creating payment events in dashboard
The final line price was calculated as qty * qty * unit price, as the
line price was multiplied with the quantity for a second time. That's no
good.
Reported in #1442. Fixes #1442.
The product status field has been removed since the tables2 PR was made.
Also added the default orderings that are also set in the models Meta
class, which means that the table headers show the applied ordering on
initial load.
As Oscar depends directly on tables2 now, it should be returned as part
of get_core_apps, and has been removed from the requirements.txt and
INSTALLED_APPS calls.
e.message has been deprecated since Python 2.6, and doesn't exist in
Python 3. Unfortunately, there's
no good generic way to get an exceptions message; e.g. Django's
VariableDoesNotExist sets e.msg, whereas ValidationError does something
quite complex.
But we rarely use the exception message, and in those cases, a simple
cast to the text type is enough.
Native migrations created with Python 2 differ from ones created with
Python 3. More importantly, they failed when used in Python 3, but not
vice versa. This is caused by field names being marked as byte strings
when using Python 2.
This rewrites the native migrations, which probably isn't a bad thing
either, because they were created with a pre-RC2 version of Django, and
Django 1.7 has since seen a few more migration-related fixes.
It's likely Django now does the correct thing and generates Python 2 and
3 compatible migrations under both versions of Python.
Remove Python 2 requirements from requirements_demo.txt
They were added in 02a13da, but I can't find an explanation for why they
were added. AFAIK, the demo site builds fine without them. Oscar doesn't
depend on them directly, and any dependencies should pull them in
automatically. Furthermore, BeautifulSoup 3 is not compatible with
Python 3.
Use updated datacash extension for Django 1.7 support
django-oscar-datacash 0.8.1 caused the demo site build process to fail;
thus failing the Travis test suite for Django 1.7. The newly released
version should fix this issue and ensure that tests pass for Django
1.7.
* Use SILENCED_SYSTEM_CHECKS warning instead of test runner hack to
avoid the warning about a change in default test runners
* Conditionally use south in the demo settings
* Add native migrations and app configs for forked apps
I missed that RC2 was released three days ago. I now follow
@djangoproject so that doesn't happen again.
The release candidate is a much saner target to test against, so let's
do that.
This means that custom deployments can reuse Oscar's test factories,
even if they're running different models.
This commit was triggered by the StockRecordFactory. The datacash
factory relied on it, but installed Oscar as a dependency and hence the
custom StockRecord model used in Oscar's test suite was not available.
They are both used in oscar.test, which means it's "public Oscar API".
Deployments might rely on e.g. the factories for their own test suite,
so all needed dependencies need to be installed as part of Oscar.
factory-boy 2.4 brings some nice, but breaking API changes.
The missing dependencies were discovered when working on
django-oscar-datacash, where some of the old-style factories are used,
but newfactories gets imported into that namespace.
Document further changes necessary when upgrading Django
The main issue is that Oscar relies on it's app configs to keep class
loading working. Hence, appropriate app configs need to be created when
upgrading.
A custom app needs to inherit from Oscar's app config. This ensures the
correct app label, and that any startup code (receivers, etc.) is
executed.
Per the camp ground rule, the fork_app command has been slightly
refactored.
get_model: Raise LookupError instead of ImportError
oscar.core.loading.get_model is a thin wrapper around Django 1.6's
get_model function. The latter returns None if the model can't be found,
whereas the Oscar variant loudly failed with an ImportError.
With Django's app refactor, most of that behaviour in Django has been
changed, and Oscar's get_model falls back to Django's
get_registered_model. But the latter raises a LookupError.
To avoid having to catch both errors, Oscar's get_model now raises a
LookupError no matter what Django version is used. This should have
minimal impact on backwards compatibility, as get_model isn't really
used outside of Oscar core.
Both the master branch and Django 1.7 branch introduced a South
migration for offers. It's been addressed by dropping the one introduced
on the Django 1.7 branch, and re-creating it.
The native migrations have been completely recreated.
Maik Hoepfel
Markus Bertheau
Johannes Schneider
Ziyad Soobhan
andysellick
David Winterbottom