search

johnpaulett / django-durationfield

Temporary reusable Django application for adding a DurationField, until Django issue #2443 is resolved.
http://django-durationfield.readthedocs.org
67 stars 24 forks source link

TBD: Return an existing Django type from get_internal_type #16

Open blueyed opened 10 years ago

blueyed commented 10 years ago

Please consider this pull request for discussion only.

btw: the tests passed before and after, although they should have failed before (for Django 1.7). I've thought that just a call to save() should have triggered an error. Maybe it's related to sqlite being used, or because of TestModels being involved?! (I could not get my hands on the durationfieldtest.db, even after commenting out "Destroying test database for alias ..." part from Django.

From the commit: This is used in Django 1.7 migrations to derive the correct database type from.

I cannot see, why "DurationField" should be returned here (added in 892b6e9).

This leaves db_type as-is, since it's used with older Django versions and South probably.

Fixes https://github.com/johnpaulett/django-durationfield/issues/15. Related Django ticket: https://code.djangoproject.com/ticket/22260

blueyed commented 10 years ago

Since https://code.djangoproject.com/ticket/22260 got fixed by reverting the change to db_type's behavior.

Still, I think we should use a return value with get_internal_type that makes sense (AFAICS).

johnpaulett commented 10 years ago

I'm not 100% sure why we return a DurationField here (perhaps @poswald might recall). Perhaps South related?

Based upon the get_internal_type documentation, it does seem like we should return an existing Django type as you suggest.

@blueyed do you know if the change to BigIntegerField works when using pre-1.7 and South (I can test, but was wondering if you already had)?

blueyed commented 10 years ago

@johnpaulett No, I have not tested it.