On 17/08/2012 4:06am, Melvyn Sopacua wrote:
On 16-8-2012 11:33, Mike Dewhirst wrote:
https://github.com/mdewhirst/split-models
Python 2.7 and Django 1.4
One of mine was getting too big and too labour-intensive to debug after
a manual split. This was due to accretion of cruft during my learning
(which hasn't stopped). So I thought I'd write a script to handle it and
my other apps as well.
Thanks for doing this! Here's a little code review:
Encoding:
- Starting django 1.5 python 3 compatibility is hitting django. If the
models.py has a __future__ line you may want to copy it verbatim,
especially the unicode_literals. You can only have one __future__ import
line so it's important to test for it and copy it.
Good point. Mine didn't have one but I knew I needed it in each
<model>.py file. At least it is easy to tweak that part of the script.
On second thoughts, from __future__ import absolute_import is needed for
1.4 but should be removed when upgrading to 1.5.
When Django was in subversion I kept more or less up to date with 1.5
but now I use the stable release 1.4 for everything.
- Perhaps do the same with editor modelines, like the one you have for
emacs. Vi(m)'s start with either vim: vi: or ex:.
Not sure what you mean here.
- Same with db_table in the Meta class. if it's not set, don't create
one: it introduces a POLA violation, cause one expects upon renaming the
model to have a new database table.
The script doesn't rename any models. My app unit tests are untouched
and work exactly the same before and after which couldn't happen if I
renamed models. Besides, there are no new database tables.
Also, db_table isn't set in any models in (my) models.py because Django
automatically constructs the table name. But it is necessary in the
separate files in the models directory.
I followed the docs and the examples here ...
On 8/08/2012 6:10pm, Russell Keith-Magee wrote:
...
https://docs.djangoproject.com/en/dev/ref/models/options/#app-label
If you want some examples of the technique in action, Django's test
suite contains an example in the "tests/modeltests/model_package"
directory.
- If you rewrite this as a django management command, you will have all
the option and argument parsing at your finger tips and can get rid of
some of the hard-coded variables and don't need the project variable
anymore.
I didn't think of manage.py. Now it is done I don't think I could
justify the time.
- I'm kind of missing the ability to "tell which models go in to which
file".
Each model goes into its own file named:
<projectroot>/<approot>/models/<model-classname>.py
and contains only the imports necessary for that model. Each individual
model is named as a specific import in:
<projectroot>/<approot>/models/__init__.py
so that other apps which relied on importing them can still do so
without modification.
If you don't intend to work on this anymore, then by all means,
disregard. I was contemplating to make this, but it's on a low priority
so for the time being this will do the trick.
As I said earlier, I hope it helps someone. I've had a lot of help from
this list.
Cheers
Mike
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
