[GSoC] Application Loading
An App Loading mechanism for Django
About Me
--
Hi everyone,
My name is Nick Sandford, I'm an electrical engineering student at the
University of Western Australia.
Background
---
I haven't been a particularly active contributor to any open source project -
here is where I hope to change that. In my current work at Christ
Church Grammar School we use Django heavily for most of our internal
projects. I've
followed django-dev closely for a couple of years and I have poked around with
its internals on various occasions.
Plan
-
Implement an improved application loading mechanism into Django.
Rationale
-
Django current application loading code is inflexible in many cases. There
exists a need for a number of extra features to be added to the way
applications are handled such as:
* The ability to internationalise application names.
* The ability to customise application names similar to ``verbose_name`` in
``model._meta``
* Deploy the same application multiple times in a single project.
* Deploy two different applications with the same name.
* Manage settings within applications.
Method
---
I don't intend to solve the third dot point of the previous list - it seems
like a difficult problem, possibly to be tackled post-GSoC. What I do intend
to do is to move towards 'application classes' more akin to
``django.contrib.admin``.
New syntax in ``settings.INSTALLED_APPS`` will be introduced to address the
previous issues. Some examples of accepted syntax:
.. sourcecode:: python
INSTALLED_APPS = (
'django.contrib.auth',
app('blog.BlogApplication', 'blog_1', 'My blog', 'app1_'),
app('blog.BlogApplication', 'blog_2', 'Some other blog', 'app2_'),
app(path='tagging.Tagging', verbose_name='My tagging application'),
app('categories', db_prefix='cat_'),
app({'path': 'django.contrib.admin.AdminApplication',
'label': 'admin',
'verbose_name': 'Secret Admin'}),
)
The ``app`` function will take four arguments, three of which are optional.
These are ``path``, ``label``, ``verbose_name``, and ``db_prefix``. It will
return an instance of an ``Application`` object, which will contain all of an
installed application's information. ``path`` will be the dotted path to a
subclass of ``Application``. The downside is that ``settings.py`` requires
an import, which may be against style rules.
.. sourcecode:: python
def app(path, label=None, verbose_name=None, db_prefix='')
if not path or not isinstance(path, basestring):
raise ImproperlyConfigured('Application path must be string.')
application_class = import_module(path)
return application_class(path, label, verbose_name, db_prefix)
``INSTALLED_APPS`` will then be a tuple containing strings or ``Application``
instances. The application loading code will iterate over ``INSTALLED_APPS``
and construct an internal cache of ``Application`` instances to be used with
``get_models``, etc. For backwards compatibility, if an element of the tuple is
a string, an instance of a base ``Application`` class will be created with sane
defaults (similar to ``app_label`` at the moment).
The ``Application`` class will be very similar to ``django.contrib.admin``'s
``AdminSite`` and will hopefully simplify application settings. If you write
views and urls directly on the ``Application`` class itself, instead of an
``from django.conf import settings`` and subsequent ``settings.API_KEY``, you
could just reference ``self.api_key`` for instance. This wouldn't be the
required, just an optional extra.
Model classes will get a ``_meta.app`` attribute, which will be an instance
of the model's ``Application`` class. Models should only be associated with one
application.
I agree with moving ``django.db.models.loading`` to ``core.apps``, since we'll
no longer require applications to have a ``models.py``. A reference to the
new functions in ``core.apps`` will still live in ``django.db.models.loading``
for backwards compatibility.
A subclass of ``Application`` might look like:
.. sourcecode:: python
from django.views.simple import direct_to_template
from djang.core.apps import Application
from blog.models import Entry, Category
class BlogApplication(Application):
models = [Entry, Category]
api_key = 'default'
def entry_detail(self, slug, request,
template_name='blog/entry_detail.html'):
entry = get_object_or_404(Entry, slug=slug)
context = {
'entry': entry,
'api_key': self.api_key,
}
Re: [GSoC] Application Loading
On Fri, Apr 9, 2010 at 3:41 AM, burc...@gmail.com wrote:
>
> Hi Nick,
>
> I don't like your application creation syntax (why using dict-based
> DSL instead of class-based?), but
> I like how you approach the overall problem.
> More than that, you have shown you do understand all the problems
> you're going to solve, and that you have design skills required for
> solution.
> But I believe you can do even further with your proposal.
>
> You said:
> >Model classes will get a ``_meta.app`` attribute, which will be an instance
> of the model's ``Application`` class. Models should only be associated with
> one
> application.
> This is very nice idea, and I think, it allows to come with further
> design of how should multiple app copies work.
> I don't want to push on you, or suggest a working solution, so I'd
> like to see your ideas.
Multiple app copies is quite a bit more difficult, unless you assume
(like the admin)
that they use the same database table. Then I guess you could store multiple
application instances in Model._meta.app and use url namespacing to
differentiate
applications/views.
>
> I've got questions that might help:
> * how will views know about their current application?
Views implemented in views.py wouldn't necessarily need to know about their
current application, but if they did, you could use get_app("my_app")
in the view itself.
Views implemented on the Application itself wouldn't have this problem.
> * how will views get their app settings after your changes?
For settings still in settings.py, just the same as always.
For settings implemented in an Application itself maybe something like:
# views.py
def view(request):
api_key = get_app("my_app").options.api_key
# do stuff
and for views in an Application:
def view(self, request):
api_key = self.options.api_key
# do stuff
> * is it a good idea to make urls properties (namespace, app_name)
> correspond with the same application properties?
That would help for the case of multiple application instances, but
for the time being
isn't strictly necessary. Probably not a bad idea to promote.
>
> Currently options are either "from django.conf import settings", and
> those settings are singleton with configuration options, or put into
> urls.
>
> Should we say "go away" to view-as-a-function and go to rails-like
> controllers like your Application class?
I don't think I necessarily want to force people to do that, but
rather make things
easier to be done like that. View-as-a-function still works well for
simple setups.
>
> (I'm for this option actually, all views other than "hello world"
> always take such a bloat of configuration options right now that needs
> to be put into controllers anyway -- look at django.contrib.auth.views
> for example!)
>
> (Completely unrelated note, but I'd rather see a url routing right
> near those views definition after update. because, 98% of times, you
> won't need urls at all!)
That would be pretty nice, you could do something like:
# urls.py
from django.conf.urls.defaults import *
from django.core.apps import get_app
urlpatterns = patterns('',
(r'^blog/', include(get_app("blog").urls)),
)
>
> Please also see the thread
> http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879?hl=en,
> there's a question you avoided delicately, about what to do with
> ForeignKey. It might also help.
As far as I see that, it's more about what to do when you have two
instances of the
same application, which I won't be attempting to solve. With just a
single instance,
models work just the same as they always have (save for the _meta.app) stuff.
Thanks for the feedback.
>
> On Thu, Apr 8, 2010 at 7:33 PM, Nick Sandford wrote:
> > An App Loading mechanism for Django
> >
> >
> > About Me
> > --
> > Hi everyone,
> >
> > My name is Nick Sandford, I'm an electrical engineering student at the
> > University of Western Australia.
> >
> > Background
> > ---
> >
> > I haven't been a particularly active contributor to any open source project
> > -
> > here is where I hope to change that. In my current work at Christ
> > Church Grammar School we use Django heavily for most of our internal
> > projects. I've
> > followed django-dev closely for a couple of years and I have poked around
> > with
> > its internals on various occasions.
> >
> > Plan
> > -
> >
> > Implement an improved appli
Re: Application Loading
On Fri, Apr 9, 2010 at 5:21 AM, Vinay Sajip wrote: > > > Have you looked at the patch on ticket 3591 which does some of this > already? Would you be using it as a starting point? It's a great place to start, and gives a good idea about where to look for problems. I'm not sure about get_installed_app_paths, rather than modifying settings.INSTALLED_APPS to contain a tuple of strings pointing to all application paths. If we end up using get_installed_app_paths it would break all of those using for app in settings.INSTALLED_APPS in third party code. You've taken the route of assuming applications won't know their models until runtime, I've expected that people explicitly assign models to apps. Your loading code looks like a good starting point also. Cheers, Nick -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: [GSoC] Application Loading
An updated proposal:
An App Loading mechanism for Django
About Me
--
Hi everyone,
My name is Nick Sandford, I'm an electrical engineering student at the
University of Western Australia.
Background
---
I haven't been a particularly active contributor to any open source project -
here is where I hope to change that. In my current work at Christ Church
Grammar School we use Django heavily for most of our internal projects. I've
followed django-dev closely for a couple of years and I have poked around with
its internals on various occasions.
Plan
-
Implement an improved application loading mechanism into Django.
Rationale
-
Django current application loading code is inflexible in many cases. There
exists a need for a number of extra features to be added to the way
applications are handled such as:
* The ability to internationalise application names.
* The ability to customise application names similar to ``verbose_name`` in
``model._meta``
* Deploy the same application multiple times in a single project.
* Deploy two different applications with the same name.
* Manage settings within applications.
Method
---
I don't intend to solve the third dot point of the previous list - it seems
like a difficult problem, possibly to be tackled post-GSoC. What I do intend
to do is to move towards 'application classes' more akin to
``django.contrib.admin``.
I plan to introduce a new file into the project structure - ``apps.py`` which
will be used to register installed applications with the ``AppCache``. I will
also move to introduce a new setting in ``settings.py``, ``APP_LOADER`` which
will be a string containing a dotted path to an application loading class. This
will serve to facilitate a move from ``settings.INSTALLED_APPS`` to the new
``apps.py``. ``APP_LOADER`` will take one of two values:
'django.core.apps.loader.legacy', which will use ``settings.INSTALLED_APPS`` or
'django.core.apps.loader.registry', which would use the new registry-based
approach. Only applications registered in ``apps.py`` in the project directory
will be registered with the ``AppCache``. The default APP_LOADER setting for
1.3 will be 'django.core.apps.loader.legacy'.
``apps.py`` will contain purely application-related setup. This should be handy
to manage application settings and to ensure ``settings.py`` doesn't get too
full of application-specific settings. This will allow us to register an app
in one of three ways something like:
.. sourcecode:: python
from django.core import apps
from blog import BlogApplication
class MyBlogApplication(BlogApplication):
api_key = 'testing'
another_blog = BlogApplication(label='blog2',
verbose_name=_('Another blog'),
api_key='anothertest')
# an application class.
apps.register(MyBlogApplication, label='blog', verbose_name=_('My blog'))
# an application instance.
apps.register(another_blog)
# old-style application.
apps.register('django.contrib.auth')
This could allow us not to touch ``settings.INSTALLED_APPS`` at all. If people
need to iterate over ``settings.INSTALLED_APPS``, a move to ``get_apps`` will
be recommended.
The ``Application`` class will be very similar to ``django.contrib.admin``'s
``AdminSite`` and will hopefully simplify application settings. If you write
views and urls directly on the ``Application`` class itself, instead of an
``from django.conf import settings`` and subsequent ``settings.API_KEY``, you
could just reference ``self.api_key`` for instance. This wouldn't be the
required, just an optional extra.
In addition to providing application settings an ``Application`` will be
required to explicitly define their models. These models could live outside
the traditional application structure, provided they are included in the
``models`` list on ``Application``. The current structure promotes strictly
requiring models for an application to reside in that application's
``models.py``. I wouldn't be promoting changing the current status quo with
regard to this, but it would be possible to deviate from it and include models
defined outside of the applications ``models.py`` on an ``Application``.
An application class would have other benefits, as evidenced by a short look at
``django.contrib.admin.AdminSite``. It could concievably be used to define a
set of 'base' add/edit/delete views for each model on an ``Application``. It
could even be used to set up an application's urls. This could make an
``Application`` class unwieldy and large however, so it won't be forced and
people can continue using views.py and urls.py as before.
Model classes will get a ``_meta.app`` attribute, which will be an instance
of the model&
Re: [GSoC] Application Loading
On Fri, Apr 9, 2010 at 2:59 PM, Russell Keith-Magee
wrote:
> On Fri, Apr 9, 2010 at 12:33 AM, Nick Sandford
> wrote:
>> An App Loading mechanism for Django
>>
>>
>> About Me
>> --
>> Hi everyone,
>>
>> My name is Nick Sandford, I'm an electrical engineering student at the
>> University of Western Australia.
>>
>> Background
>> ---
>>
>> I haven't been a particularly active contributor to any open source project -
>> here is where I hope to change that. In my current work at Christ
>> Church Grammar School we use Django heavily for most of our internal
>> projects. I've
>> followed django-dev closely for a couple of years and I have poked around
>> with
>> its internals on various occasions.
>
> Ok - I clearly need to get a Perth DjUG going...
>
>> Plan
>> -
>>
>> Implement an improved application loading mechanism into Django.
>>
>> Rationale
>> -
>>
>> Django current application loading code is inflexible in many cases. There
>> exists a need for a number of extra features to be added to the way
>> applications are handled such as:
>>
>> * The ability to internationalise application names.
>> * The ability to customise application names similar to ``verbose_name`` in
>> ``model._meta``
>> * Deploy the same application multiple times in a single project.
>> * Deploy two different applications with the same name.
>> * Manage settings within applications.
>>
>> Method
>> ---
>>
>> I don't intend to solve the third dot point of the previous list - it seems
>> like a difficult problem, possibly to be tackled post-GSoC. What I do intend
>> to do is to move towards 'application classes' more akin to
>> ``django.contrib.admin``.
>>
>> New syntax in ``settings.INSTALLED_APPS`` will be introduced to address the
>> previous issues. Some examples of accepted syntax:
>>
>> .. sourcecode:: python
>>
>> INSTALLED_APPS = (
>> 'django.contrib.auth',
>> app('blog.BlogApplication', 'blog_1', 'My blog', 'app1_'),
>> app('blog.BlogApplication', 'blog_2', 'Some other blog', 'app2_'),
>> app(path='tagging.Tagging', verbose_name='My tagging application'),
>> app('categories', db_prefix='cat_'),
>> app({'path': 'django.contrib.admin.AdminApplication',
>> 'label': 'admin',
>> 'verbose_name': 'Secret Admin'}),
>> )
>>
>> The ``app`` function will take four arguments, three of which are optional.
>> These are ``path``, ``label``, ``verbose_name``, and ``db_prefix``. It will
>> return an instance of an ``Application`` object, which will contain all of an
>> installed application's information. ``path`` will be the dotted path to a
>> subclass of ``Application``. The downside is that ``settings.py`` requires
>> an import, which may be against style rules.
>>
>> .. sourcecode:: python
>>
>> def app(path, label=None, verbose_name=None, db_prefix='')
>> if not path or not isinstance(path, basestring):
>> raise ImproperlyConfigured('Application path must be string.')
>> application_class = import_module(path)
>> return application_class(path, label, verbose_name, db_prefix)
>>
>> ``INSTALLED_APPS`` will then be a tuple containing strings or ``Application``
>> instances. The application loading code will iterate over ``INSTALLED_APPS``
>> and construct an internal cache of ``Application`` instances to be used with
>> ``get_models``, etc. For backwards compatibility, if an element of the tuple
>> is
>> a string, an instance of a base ``Application`` class will be created with
>> sane
>> defaults (similar to ``app_label`` at the moment).
>>
>> The ``Application`` class will be very similar to ``django.contrib.admin``'s
>> ``AdminSite`` and will hopefully simplify application settings. If you write
>> views and urls directly on the ``Application`` class itself, instead of an
>> ``from django.conf import settings`` and subsequent ``settings.API_KEY``, you
>> could just reference ``self.api_key`` for instance. This wouldn't be the
>> required, just an optional extra.
>>
>> Model classes will get a ``_meta.app`` attribute, which will
Overriding AppConfig.get_model(s)
I was just working on #22986 and it seems that if the AppConfig.get_model(s) methods are overridden, migrations for models that are excluded are still run. Is this a known issue? Am I abusing get_model(s) or should I file a ticket for this? Cheers, Nick https://code.djangoproject.com/ticket/22986#comment:5 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Overriding AppConfig.get_model(s)
Ahh ok, that makes sense -- I guess there's no difference between overriding get_model(s) and manually deleting the model out of the source to the migrations. I can't think of any decent way to use router.allow_migrate in sessions other than monkey patching it to do what I want. Any suggestions? Would it be possible to detect that the models are being manually excluded rather than removed from the source and migrate them differently? Cheers, Nick On Fri, Jul 25, 2014 at 8:05 PM, Andrew Godwin wrote: > Migrations instantiate their own copies of AppConfig and Apps and run from > those, so you won't be able to affect them by overriding methods. If you > want to exclude models from migrations use router.allow_migrate. > > Andrew > > > On Fri, Jul 25, 2014 at 11:59 AM, Nick Sandford > wrote: > >> I was just working on #22986 and it seems that if the >> AppConfig.get_model(s) methods are overridden, migrations for models that >> are excluded are still run. >> >> Is this a known issue? Am I abusing get_model(s) or should I file a >> ticket for this? >> >> Cheers, >> Nick >> >> https://code.djangoproject.com/ticket/22986#comment:5 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To post to this group, send email to django-developers@googlegroups.com. >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAFwN1upTQN2ATv4btfrnSCybBZ4CHR7pGXV%3Dc%3Dbe6nm7Wh9JKw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAFwN1upTQN2ATv4btfrnSCybBZ4CHR7pGXV%3Dc%3Dbe6nm7Wh9JKw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwcc5WrEHhwA-U3h8R4qUa8mBvUd%2BXz%2BgSjwb0H8Yz6LAaVsA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Overriding AppConfig.get_model(s)
Isn't that essentially what's happening by respecting router.allow_migrate? Determining at runtime via a setting (DATABASE_ROUTERS) whether to apply migrations. From the perspective of a user, providing a custom database router makes sense for applications they don't control, but from the perspective of an reusable app developer who doesn't have access to the project's settings, using database routers seems a bit more cumbersome. I guess I'm just thinking that having an alternative method would be useful. I'm happy to help find a solution if you feel it's a worthwhile pursuit. Cheers, Nick On Fri, Jul 25, 2014 at 9:02 PM, Andrew Godwin wrote: > I don't think there's a way you can do this with migrations. You're not > supposed to be able to change them at runtime based on settings; that was > the cause of most of our bugs with swappable models. > > Andrew > > > On Fri, Jul 25, 2014 at 12:48 PM, Nick Sandford > wrote: > >> Ahh ok, that makes sense -- I guess there's no difference between >> overriding get_model(s) and manually deleting the model out of the source >> to the migrations. >> >> I can't think of any decent way to use router.allow_migrate in sessions >> other than monkey patching it to do what I want. Any suggestions? >> >> Would it be possible to detect that the models are being manually >> excluded rather than removed from the source and migrate them differently? >> >> Cheers, >> Nick >> >> >> On Fri, Jul 25, 2014 at 8:05 PM, Andrew Godwin >> wrote: >> >>> Migrations instantiate their own copies of AppConfig and Apps and run >>> from those, so you won't be able to affect them by overriding methods. If >>> you want to exclude models from migrations use router.allow_migrate. >>> >>> Andrew >>> >>> >>> On Fri, Jul 25, 2014 at 11:59 AM, Nick Sandford >> > wrote: >>> >>>> I was just working on #22986 and it seems that if the >>>> AppConfig.get_model(s) methods are overridden, migrations for models that >>>> are excluded are still run. >>>> >>>> Is this a known issue? Am I abusing get_model(s) or should I file a >>>> ticket for this? >>>> >>>> Cheers, >>>> Nick >>>> >>>> https://code.djangoproject.com/ticket/22986#comment:5 >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Django developers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to django-developers+unsubscr...@googlegroups.com. >>>> To post to this group, send email to django-developers@googlegroups.com >>>> . >>>> Visit this group at http://groups.google.com/group/django-developers. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/django-developers/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-developers+unsubscr...@googlegroups.com. >>> To post to this group, send email to django-developers@googlegroups.com. >>> Visit this group at http://groups.google.com/group/django-developers. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/CAFwN1upTQN2ATv4btfrnSCybBZ4CHR7pGXV%3Dc%3Dbe6nm7Wh9JKw%40mail.gmail.com >>> <https://groups.google.com/d/msgid/django-developers/CAFwN1upTQN2ATv4btfrnSCybBZ4CHR7pGXV%3Dc%3Dbe6nm7Wh9JKw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To post to this group, send email to django-developers@google
Re: Overriding AppConfig.get_model(s)
Managed might be the ticket then. I don't think it's too surprising to the user who configures a cache or file session backend that no database table is created. I think that's slightly less surprising than the status quo -- they configured a file session backend and when they run migrate they notice that a database table for sessions has been created, which might lead them to question if the session backend is working as intended. I'll pursue the meta option for now :). If they start with the database backend, and switch at a later date to a non-database backend, then I'm comfortable to make it the user's responsibility to clean up the leftover database table, but were you suggesting if they start with a non-database backend and at some later stage decide to switch to a database backend it won't work? Thanks for the help. Nick On Fri, Jul 25, 2014 at 9:24 PM, Andrew Godwin wrote: > Yeah, but if you change the value of the routers during a project's > lifetime it's up to you to fix the resulting issues (same as if you switch > AUTH_USER_MODEL - you _cannot_ change this after project start without > serious pain). > > If you're happy saying the same thing about sessions, then go and tie the > model's managed option to the setting - that should do what you want - but > people are going to get real confused when they change the setting and the > table isn't made for them. > > Andrew > > > On Fri, Jul 25, 2014 at 1:17 PM, Nick Sandford > wrote: > >> Isn't that essentially what's happening by respecting >> router.allow_migrate? Determining at runtime via a setting >> (DATABASE_ROUTERS) whether to apply migrations. From the perspective of a >> user, providing a custom database router makes sense for applications they >> don't control, but from the perspective of an reusable app developer who >> doesn't have access to the project's settings, using database routers seems >> a bit more cumbersome. >> >> I guess I'm just thinking that having an alternative method would be >> useful. I'm happy to help find a solution if you feel it's a worthwhile >> pursuit. >> >> Cheers, >> Nick >> >> >> On Fri, Jul 25, 2014 at 9:02 PM, Andrew Godwin >> wrote: >> >>> I don't think there's a way you can do this with migrations. You're not >>> supposed to be able to change them at runtime based on settings; that was >>> the cause of most of our bugs with swappable models. >>> >>> Andrew >>> >>> >>> On Fri, Jul 25, 2014 at 12:48 PM, Nick Sandford >> > wrote: >>> >>>> Ahh ok, that makes sense -- I guess there's no difference between >>>> overriding get_model(s) and manually deleting the model out of the source >>>> to the migrations. >>>> >>>> I can't think of any decent way to use router.allow_migrate in sessions >>>> other than monkey patching it to do what I want. Any suggestions? >>>> >>>> Would it be possible to detect that the models are being manually >>>> excluded rather than removed from the source and migrate them differently? >>>> >>>> Cheers, >>>> Nick >>>> >>>> >>>> On Fri, Jul 25, 2014 at 8:05 PM, Andrew Godwin >>>> wrote: >>>> >>>>> Migrations instantiate their own copies of AppConfig and Apps and run >>>>> from those, so you won't be able to affect them by overriding methods. If >>>>> you want to exclude models from migrations use router.allow_migrate. >>>>> >>>>> Andrew >>>>> >>>>> >>>>> On Fri, Jul 25, 2014 at 11:59 AM, Nick Sandford < >>>>> nick.sandf...@gmail.com> wrote: >>>>> >>>>>> I was just working on #22986 and it seems that if the >>>>>> AppConfig.get_model(s) methods are overridden, migrations for models that >>>>>> are excluded are still run. >>>>>> >>>>>> Is this a known issue? Am I abusing get_model(s) or should I file a >>>>>> ticket for this? >>>>>> >>>>>> Cheers, >>>>>> Nick >>>>>> >>>>>> https://code.djangoproject.com/ticket/22986#comment:5 >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Django developers" group. >>>&g
Re: Proposal: Write unit tests for JavaScript
So, I have been working a little on a PR for this ( https://github.com/django/django/pull/3003) and having spoken to Tim briefly about getting this supported in jenkins I just wanted to check that the approach was OK. The tests use node, grunt, qunit, istanbul and jshint. Is this a reasonable approach? Some of the responses here are using a similar stack. On Mon, May 5, 2014 at 7:19 AM, Trey Hunner wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I started a rough draft of a DEP for adding unit tests for Django's > JavaScript: https://github.com/django/deps/pull/4 > > I am suggesting that a native JavaScript test framework be used > *without* attempting to use an adapter to run the tests under the Django > test framework. I anticipate that this suggestion may require further > explanation and debate, so I have submitted a pull request for > discussion while I continue to extend the DEP. > > - -- > Trey Hunner > http://treyhunner.com > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJTZy2KAAoJEOpnfp/Nreona8oIAKBE0T05wmnCP0tq/nvmQIlC > 0KWB0bX47FHn3TeOjEK8dHrxebP9UDL+wmdZ8F23iOQnW8OiJIO3dJjSjqLOAXxg > dNh5imq02kY2rvjVB6ypZp0h+INkQoaQMae5xMdN4RozLnbNrgXln7vbuSrjIB/8 > z7h983vqiRp/ofa+2urTnUnC63730gg6vBbXE5EQ+5WeJxqx2yahdbeSmB3oCnhD > 7TMRdHYY+Tx1bdsHF3KOniKoHXA0qoeV16RK+J7EWRHMo3eKlH1zOpcbNX8klwed > qF2zZSKFqMIj0H/mBOVWy5uePXUOfIOP4iLTjEuSy+6sPDNPCiPAvCE5R9jyz/k= > =/i9B > -END PGP SIGNATURE- > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/53672D8A.2050005%40treyhunner.com > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwcc5WuxZ5yVQQH8wVbX51VHyaXN-ZLyrK_oJeS3e4vo5kqvA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
