Re: GSoC: App Loading
Good idea. Let INSTALLED_APPS be iterable, and let Django deployment
do its job based on the configuration. Little to say though:
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.admin',
'foo.gsoc',
('foo.gsoc', 'taiwan', {'verbose_name': _('GSoC'), \
'lang': 'zh-TW', \
'name': 'gsoc_tw', \
'db_prefix': 'gsoctw_', \
'skin': 'orient'}),
)
So that app-level configuration would have been satisfied:
Internationalization of the app name in admin, differentiated db
prefices, default highlighting language for the app, etc.
Every existence of an app will be defined as namespace URL in the
code, thus no app with duplicate name. For instance: 'foo.gsoc' is
named 'foo.gsoc' and models are accessed as 'from foo.gsoc.models
import Idea', while '('foo.gsoc', 'taiwan', ..)' would be named as
'foo.gsoc.taiwan' if 'name' in dict is not existent, and like
'gsoc_tw' if 'name' attribute exists. Maybe 'name' and 'db_prefix'
would be associated.
Integration of a model with another model in a different app would be
simpler, since everything is namespace-based:
class Idea(models.Model):
title = models.CharField(max_length=200)
description = models.CharField(max_length=200)
organization = models.ForeignKey(foo.gsoc.models.Organization,
to_field='name') # notice full path
> Russell Keith-Magee
> wrote:
>> Providing configurability for 'app level' settings; for example,
>> when deploying contrib.comments, setting the name of the model that
>> will be used for content.
In addition, yet most important, the extra dict (attributes) in the
tuple declaration of an app in INSTALLED_APPS will be stored in a
module like 'foo.gsoc.ATTR', so that the application itself can
access, hence providing a dynamic (configured app-level, rather than
hard-coded in a model) app-level configuration.
On Wed, Apr 7, 2010 at 5:26 PM, Jannis Leidel wrote:
>
> Am 07.04.2010 um 13:40 schrieb Russell Keith-Magee:
>
>> On Mon, Apr 5, 2010 at 5:35 AM, Arthur Koziel
>> wrote:
>>> Hi,
>>> I’m going to apply for GSoC with the goal of refactoring the app loading
>>> [0]. I’ve been looking at Django’s current app loading implementation
>>> (db.models.loading), Vinay Sajip’s patch in #3591 [1] and the notes on the
>>> InstalledAppsRevision wiki page [2]. Here's what I'm planning to change. Any
>>> feedback is appreciated.
>>> Step 1
>>> -
>>> Deal with the two main problems of the current app loading implementation,
>>> and make it possible to:
>>> - deploy several instances of the same app
>>> - deploy two apps with the same name
>>> The INSTALLED_APPS setting will be changed to:
>>>
>>> INSTALLED_APPS = InstalledApps(
>>> 'django.contrib.auth', # strings will be converted to App()
>>
>> Strings will be converted to App()... by What? When?
>>
>> What happens to existing code that is using "for app in INSTALLED_APS"
>> as an idiom?
>
> I'm worried that creating the app instances with an ``app()`` callable would
> require an import and contradicts with the convention of having dotted paths
> for any configurable extension. That's why I think INSTALLED_APPS should be
> kept as an iterable of dotted paths which is converted to an app registry
> during the start-up (which already happens for wildcard entries like
> "django.contrib.*"). Each entry of the list would be a string with one of the
> following values:
>
> - Dotted path to an app module (current default, e.g. 'django.contrib.auth').
> During the start-up an anonymous app instance would be initialized, using the
> models module of the loaded app module.
>
> - Dotted path to an app class (e.g. 'django.contrib.auth.AuthApp'). During
> the start-up a named app instance would be created, either with the models
> module of the module the app class is located in, the model attribute of the
> class or none (model-less app).
>
> - Dotted path to an app instance (e.g. 'django.contrib.admin.site'). During
> the start-up an existing app instance would be handled like it has been
> loaded in one of the former two cases.
>
> Iterating over the INSTALLED_APPS setting would still be supported given the
> fact each app instance has it's own label that sets its models db_prefix, so
> the check for a custom app would be:
>
> if "acme.auth" in INSTALLED_APPS:
> # do something
>
> An app class could look like this:
>
> from django.contrib import auth
> from django.conf.urls.defaults import patterns
> from django.utils.translation import ugettext_lazy as _
>
> class AcmeAuthApp(auth.AuthApp):
> label = 'acme' # sets the db_prefix
> models = auth.models
> verbose_name = _('acme auth')
>
> def get_urls(self):
> return patterns('acme.auth.views',
> url(r'^login/$', 'login', name="acme_auth_login"),
> )
>
> Jannis
>
> --
> You rece
Re: [GSOC] NoSQL Support for the ORM
Hi all, On Thu, Apr 8, 2010 at 12:55 AM, Waldemar Kornewald wrote: > On Wed, Apr 7, 2010 at 5:22 PM, Alex Gaynor wrote: >>> Other issues that spring to mind: [...] > Well, you might be able to quickly adapt the MongoDB backend to GAE > (within GSoC time constraints) due to their similarity. Anyway, there > is common ground between the NoSQL DBs, but this highly depends on > what problem we agree to solve. If we only provide exactly the > features that each DB supports natively, they'll appear dissimilar > because they take very different approaches to indexing and if this > isn't abstracted and automated NoSQL support doesn't really make sense > with Django. OTOH, if the goal is to make an abstraction around their > indexes they can all look very similar from the perspective of > Django's ORM (of course they have different "features" like sharding > or eventual consistency or being in-memory DBs or supporting fast > writes or reads or having transactions or ..., but in the end only few > of these features have any influence on Django's ORM, at all). > > Bye, > Waldemar Kornewald Could we switch to one issue/feature per thread, please? I think the overall approach is chosen already, and everyone agreed with it. And each detail now has to be discussed separately, and overall discussion continued here. I.e, I have few words about design of counters and indexes (and my favorite NoSQL Berkeley DB), but not arrays/lists. -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- 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: App Loading
On Thu, Apr 8, 2010 at 2:56 PM, Dagvadorj Galbadrakh
wrote:
> Good idea. Let INSTALLED_APPS be iterable, and let Django deployment
> do its job based on the configuration. Little to say though:
>
> INSTALLED_APPS = (
> 'django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.sites',
> 'django.contrib.admin',
> 'foo.gsoc',
> ('foo.gsoc', 'taiwan', {'verbose_name': _('GSoC'), \
> 'lang': 'zh-TW', \
> 'name': 'gsoc_tw', \
> 'db_prefix': 'gsoctw_', \
> 'skin': 'orient'}),
> )
>
> So that app-level configuration would have been satisfied:
> Internationalization of the app name in admin, differentiated db
> prefices, default highlighting language for the app, etc.
>
> Every existence of an app will be defined as namespace URL in the
> code, thus no app with duplicate name. For instance: 'foo.gsoc' is
> named 'foo.gsoc' and models are accessed as 'from foo.gsoc.models
> import Idea', while '('foo.gsoc', 'taiwan', ..)' would be named as
> 'foo.gsoc.taiwan' if 'name' in dict is not existent, and like
> 'gsoc_tw' if 'name' attribute exists. Maybe 'name' and 'db_prefix'
> would be associated.
May I have few questions.
1) And what if foo.gsoc has taiwan submodule already?
2) How will module know what name(s) it has got?
3) How will different application names to be referenced from outside?
3) How will different application names to be loaded from outside?
I believe, the only way is to have a module for each application copy.
so you've got:
conf/gsoc.py
class App():
option1 = 'value1'
modules = 'apps.gsoc'
etc.
conf/taiwan.py:
import gsoc
class App(gsoc.App):
option1 = override
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--
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: App Loading
Thanks for review. On Thu, Apr 8, 2010 at 3:15 PM, burc...@gmail.com wrote: > > May I have few questions. > 1) And what if foo.gsoc has taiwan submodule already? There will be certain conventions on which names not to use as an instance name such as, views, models, etc. Plus, Django can check if a module with the same name exists during deployment. And also, new instances can be stored in a special module called 'clone' for instance, hence, 'foo.gsoc.clone.taiwan'. > 2) How will module know what name(s) it has got? Can be stored in dict in AppCache > 3) How will different application names to be referenced from outside? > 3) How will different application names to be loaded from outside? The apps and its modules will be referenced by its namespace (path - virtual). -- Dagvadorj GALBADRAKH -- 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: App Loading
On Thu, Apr 8, 2010 at 3:27 PM, Dagvadorj Galbadrakh wrote: > Thanks for review. > > On Thu, Apr 8, 2010 at 3:15 PM, burc...@gmail.com wrote: >> >> May I have few questions. >> 1) And what if foo.gsoc has taiwan submodule already? > > There will be certain conventions on which names not to use as an > instance name such as, views, models, etc. Plus, Django can check if a > module with the same name exists during deployment. And also, new > instances can be stored in a special module called 'clone' for > instance, hence, 'foo.gsoc.clone.taiwan'. That's better. "clone" is a horrible name for this purpose, but I got the idea. >> 2) How will module know what name(s) it has got? > > Can be stored in dict in AppCache > >> 3) How will different application names to be referenced from outside? >> 3) How will different application names to be loaded from outside? > > The apps and its modules will be referenced by its namespace (path - virtual). I believe you don't quite understand all the problems, so i'll add more details here. I repeat fragments of Flo's post nobody has answered yet: Assume an app1 which requires another app2 (gsoc in your case), and has some ForeignKeys to it. Currently that's easy; just import the model and ForeignKey it. How would those imports look like in your case (eg to which models would app1 link)?! Also, will app2copy (taiwan in you case) have different models than app2 (gsoc)? (The same for views working with these models etc) We don't have currently a way application's view knows about what instance they work with. This is a critical issue, and nobody yet suggested proper solution for that. All that both of you can suggest us now is "I am suitable to make a patch in an hour that will make multiple app copies work sometimes" approach. You need to question yourself about all possible problems. And write your solutions to them. Not wait when we will ask you those questions. Because all those questions are already in this google group (not only this thread). Read all related topics, write questions, answer them. And then come to us with a proposal. I'm sure both of you can qualify if you do this. -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- 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: App Loading
Thanks for the brilliant advice. I will do so and am now. :) On Thu, Apr 8, 2010 at 6:09 PM, burc...@gmail.com wrote: > On Thu, Apr 8, 2010 at 3:27 PM, Dagvadorj Galbadrakh > wrote: >> Thanks for review. >> >> On Thu, Apr 8, 2010 at 3:15 PM, burc...@gmail.com wrote: >>> >>> May I have few questions. >>> 1) And what if foo.gsoc has taiwan submodule already? >> >> There will be certain conventions on which names not to use as an >> instance name such as, views, models, etc. Plus, Django can check if a >> module with the same name exists during deployment. And also, new >> instances can be stored in a special module called 'clone' for >> instance, hence, 'foo.gsoc.clone.taiwan'. > That's better. > "clone" is a horrible name for this purpose, but I got the idea. > >>> 2) How will module know what name(s) it has got? >> >> Can be stored in dict in AppCache >> >>> 3) How will different application names to be referenced from outside? >>> 3) How will different application names to be loaded from outside? >> >> The apps and its modules will be referenced by its namespace (path - >> virtual). > I believe you don't quite understand all the problems, > so i'll add more details here. > > I repeat fragments of Flo's post nobody has answered yet: > > Assume an app1 which requires another app2 (gsoc in your case), and has some > ForeignKeys to it. Currently that's easy; just import the model and > ForeignKey it. How would those imports look like in your case (eg to > which models would app1 link)?! > > Also, will app2copy (taiwan in you case) have different models than app2 > (gsoc)? > (The same for views working with these models etc) > > We don't have currently a way application's view knows about what > instance they work with. > > This is a critical issue, and nobody yet suggested proper solution for that. > > All that both of you can suggest us now is "I am suitable to make a > patch in an hour that will make multiple app copies work sometimes" > approach. > > You need to question yourself about all possible problems. > And write your solutions to them. > Not wait when we will ask you those questions. > Because all those questions are already in this google group (not only > this thread). > Read all related topics, write questions, answer them. > And then come to us with a proposal. > I'm sure both of you can qualify if you do this. > > -- > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, > MSN: bu...@live.com > > -- > 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. > > -- Dagvadorj GALBADRAKH -- 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: NoSQL Support for the ORM
On Wed, Apr 7, 2010 at 4:43 PM, Waldemar Kornewald wrote: > On Wed, Apr 7, 2010 at 5:12 PM, Alex Gaynor wrote: >> No. I am vehemently opposed to attempting to extensively emulate the >> features of a relational database in a non-relational one. People >> talk about the "object relational" impedance mismatch, much less the >> "object-relational non-relational" one. I have no interest in >> attempting to support any attempts at emulating features that just >> don't exist on the databases they're being emulated on. > > This decision has to be based on the actual needs of NoSQL developers. > Did you actually work on non-trivial projects that needed > denormalization and in-memory JOINs and manually maintained counters? > I'm not making this up. The "dumb" key-value store API is not enough. > People are manually writing lots of code for features that could be > handled by an SQL emulation layer. Do we agree until here? > No, we don't. People are desiging there data in ways that fit their datastore. If all people did was implement a relational model in userland code on top of non-relational databases then they'd really be missing the point. > Then, the question boils down to: Is the ORM the right place to handle > those features? > > We see more advantages in moving those features into the ORM instead > of some separate API: > No matter whether you do denormalization or an in-memory JOIN, you end > up emulating an SQL-like JOIN. When you're maintaining a counter you > again do a simple and very common operation supported by SQL: > counting. Django's ORM already provides that functionality. Django's > current reusable apps already use that functionality. Developers > already know Django's ORM and thus also that functionality. By moving > these features into the ORM > * existing Django apps will either work directly on NoSQL or at least > be much easier to port Not a design concern. People expecting programs designed for totally separate data models to work should expect to be disappointed. Unless you're using the limited subset of features supported by all databases, of course. > * Django apps written for NoSQL will be portable across all NoSQL DBs > without any code changes and in the worst case require only minor > changes to switch to SQL > * the resulting code is shorter and easier to understand than with a > separate API which would only add another layer of indirection you'd > have to think about *every* (!) single time you work with models (and > if you have to think about this while writing model code you end up > with potentially a lot more bugs, as is actually the case in practice) > * developers won't have to use and learn a different models API (you'd > only need to learn an API for specifying "optimization" rules, but the > models would still be the same) > Uhh, the whole point of htis is that there is only a single API. > App Engine's indexes are not that different from what we propose. Like > many other NoSQL DBs, the datastore doesn't create indexes for all > possible queries. Sometimes you'll need a composite index to make > certain queries work. On Cassandra, CouchDB, Redis, and many other > "crippled" NoSQL DBs you solve this problem by maintaining even the > most trivial DB indexes with manually written indexing *code* (and I > mean *anything* that filters on fields other than the primary key). I > bet five years ago database developers would've called anyone nuts > who'd seriously suggest that nonsense, but somehow the NoSQL hype > makes developers forget about productivity. Anyway, on App Engine, > instead of writing code for those trivial indexes you add a simple > index definition to your index.yaml (actually, it's automatically > generated for you based on the queries you execute) and suddenly the > normal query API supports the respective filter rules transparently > (with exactly the same API; this is in strong contrast to Cassandra, > etc. which also make you manually write code for traversing those > manually implemented indexes! basically, they make you implement a > little specialized DB for every project and this is no joke, but the > sad truth). Now, our goal is to bring App Engine's indexing > definitions to the next level and allow to specify denormalization and > other "advanced" indexing rules which make more complicated queries > work transparently, again via the same API that everyone already > knows. > > Instead of seeing this as object-relational non-relational mapping you > should see this as an object-relational mapping for a type of DB that > needs explicitly specified indexing rules for complex queries (which, > if you really think about it, exactly describes what working with > NoSQL DBs is like). > >>> In addition to these changes you'll also need to take care of a few >>> other things: >>> >>> Many NoSQL DBs provide a simple "upsert"-like behavior where on save() >>> they either create a new entity if none exists with that primary key >>> or update the
Re: [GSOC] NoSQL Support for the ORM
On Wed, Apr 7, 2010 at 5:55 PM, Waldemar Kornewald wrote: > On Wed, Apr 7, 2010 at 5:22 PM, Alex Gaynor wrote: >>> Other issues that spring to mind: >>> >>> * What about nonSQL datatypes? List/Set types are a common feature of >>> Non-SQL backends, and are The Right Way to solve a whole bunch of >>> problems. How do you propose to approach these datatypes? What (if >>> any) overlap exists between the use of set data types and m2m? Is >>> there any potential overlap between supporting List/Set types and >>> supporting Arrays in SQL? >>> >> >> Is there overlap between List/Set and Arrays in SQL? Probably. In my >> opinion there's no reason, once we have a good clean seperation of >> concerns in the architecture that implementing a ListField would be >> particularly hard. If we happened to include one in Django, all the >> better (from the perspective of interoperability). > > Do all SQL DBs provide an array type? PostgreSQL has it and I think it > can exactly mimic NoSQL lists, but I couldn't find an equivalent in > sqlite and MySQL. Does this possibly stand in the way of integrating > an official ListField into Django or is it OK to have a field that > isn't supported on all DBs? Or can we fall back to storing the list > items in separate entities in that case? > I'd be -1 on using a separate entity, if it's supported it is, if not it's not. There's no reason it has to be included in Django in any event (certainly none of the non-relational backends will be, at least to start with). >>> * How does a non-SQL backend integrate with syncdb and other setup >>> tools? What about inspectdb? >>> >> >> Most, but not all non-relational databases don't require table setup >> the way relational DBs do. MongoDB doesn't require anything at all, >> by contrast Cassandra requires an XML configuration file. How to >> handle these is a little touchy, but basically I think syncdb should >> stay conceptually pure, generating "tables", if extra config is needed >> backends should ship custom management commands. > > Essentially, I agree, but I would add things like auto-generated > CouchDB views to the syncdb process (since syncdb on SQL already takes > care of creating indexes, too). > >>> * Why the choice of MongoDB specifically? Do you have particular >>> experience with MongoDB? Does MongoDB have features that make it a >>> good choice? >>> >> >> MongoDB offers a wide range of filtering options, which from my >> perspective means it presents a greater test of the flexibility of the >> developed APIs. For this reason GAE would also be a good choice. >> Something like Riak or Cassandra, which basically only have native >> support for get(pk=3) would be a poor test of the flexibility of the >> API. > > MongoDB really is a good choice. Out-of-the-box (without manual index > definitions) it provides more features than GAE and most other NoSQL > DBs. MongoDB and GAE should also have the simplest backends. > > Why should the Cassandra/CouchDB/Riak/Redis/etc. backend only support > pk=... queries? There's no reason why the backend couldn't maintain > indexes for the other fields and transparently support filters on any > field. I mean, you don't really want developers to manually create and > query separate indexing models for mapping one field value to its > respective primary key in the primary model table. We can do much > better than that. > Because that's all they support out of the box. You call it maintaining an index, but it really means setting up a separate "table" (in RDBMS parlance) and I think that's a level of emulation that's far beyond what should be supported out of the box. In any event I can't stop someone from writing a backend that does do that level of abstraction. >>> * Given that you're only proposing a single proof-of-concept backend, >>> have you given any thought to the needs of other backends? It's not >>> hard to envisage that Couch, Cassandra, GAE etc will all have slightly >>> different requirements and problems. Is there a common ground that >>> exists between all data store backends? If there isn't, how do you >>> know that what you are proposing will be sufficient to support them? >>> >> >> To a certain extent this is a matter of knowing the featuresets of the >> databases and, hopefully, having a mentor who is knowledgeable about >> them. The reality is under the GSOC time constraints attempting to >> write complete backends for multiple databases would probably be >> impossible. > > Well, you might be able to quickly adapt the MongoDB backend to GAE > (within GSoC time constraints) due to their similarity. Anyway, there > is common ground between the NoSQL DBs, but this highly depends on > what problem we agree to solve. If we only provide exactly the > features that each DB supports natively, they'll appear dissimilar > because they take very different approaches to indexing and if this > isn't abstracted and automated NoSQL support doesn't really make sense > with Django. O
[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,
}
return direct_to_template(request, template_name, context)
Hurdles
There are a list of possible technical issues:
* Introducing the new ``app`` function requires an import in settings.py
which might not be acceptable behaviour.
* Two applications with the same label.
* Worrying amounts
Re: NoSQL Support for the ORM
On Thu, Apr 8, 2010 at 6:14 PM, Alex Gaynor wrote:
> On Wed, Apr 7, 2010 at 4:43 PM, Waldemar Kornewald
> wrote:
>> On Wed, Apr 7, 2010 at 5:12 PM, Alex Gaynor wrote:
>>> No. I am vehemently opposed to attempting to extensively emulate the
>>> features of a relational database in a non-relational one. People
>>> talk about the "object relational" impedance mismatch, much less the
>>> "object-relational non-relational" one. I have no interest in
>>> attempting to support any attempts at emulating features that just
>>> don't exist on the databases they're being emulated on.
>>
>> This decision has to be based on the actual needs of NoSQL developers.
>> Did you actually work on non-trivial projects that needed
>> denormalization and in-memory JOINs and manually maintained counters?
>> I'm not making this up. The "dumb" key-value store API is not enough.
>> People are manually writing lots of code for features that could be
>> handled by an SQL emulation layer. Do we agree until here?
>>
>
> No, we don't. People are desiging there data in ways that fit their
> datastore. If all people did was implement a relational model in
> userland code on top of non-relational databases then they'd really be
> missing the point.
Then you're calling everyone a fool. :) What do you call a CouchDB or
Cassandra index mapping usernames to user pks? Its purpose it exactly
to do something that relational DBs provides out-of-the-box. You can't
deny that people do in fact manually maintain such indexes.
So, you're suggestion to write code like this:
# --
class User(models.Model):
username = models.CharField(max_length=200)
email = models.CharField(max_length=200)
...
class UsernameUser(models.Model):
username = models.CharField(primary_key=True, max_length=200)
user_id = models.IntegerField()
class EmailUser(models.Model):
email = models.CharField(primary_key=True, max_length=200)
user_id = models.IntegerField()
def add_user(username, email):
user = User.objects.create(username=username, email=email)
UsernameUser.objects.create(username=username, user_id=user.id)
EmailUser.objects.create(email=email, user_id=user.id)
return user
def get_user_by_username(username):
id = UsernameUser.objects.get(username=username).user_id
return User.objects.get(id=id)
def get_user_by_email(email):
id = EmailUser.objects.get(email=email).user_id
return User.objects.get(id=id)
get_user_by_username('marcus')
get_user_by_email('mar...@marcus.com')
# --
What I'm proposing allows you to just write this:
# --
class User(models.Model):
username = models.CharField(max_length=200)
email = models.CharField(max_length=200)
...
User.objects.get(username='marcus')
User.objects.get(email='mar...@marcus.com')
# --
Are you seriously saying that people should use the first version of
the code when they work with a simplistic NoSQL DB (note, it's how
they work today with those DBs)?
>> * Django apps written for NoSQL will be portable across all NoSQL DBs
>> without any code changes and in the worst case require only minor
>> changes to switch to SQL
>> * the resulting code is shorter and easier to understand than with a
>> separate API which would only add another layer of indirection you'd
>> have to think about *every* (!) single time you work with models (and
>> if you have to think about this while writing model code you end up
>> with potentially a lot more bugs, as is actually the case in practice)
>> * developers won't have to use and learn a different models API (you'd
>> only need to learn an API for specifying "optimization" rules, but the
>> models would still be the same)
>>
>
> Uhh, the whole point of htis is that there is only a single API.
And what you're suggesting is an API whose semantics are different on
every single backend? How is that better? The indexing API would at
least look and behave the same on all backends, so it's a "learn once
and use anywhere" experience.
>> What if you filter on one field defined in the parent class and
>> another field defined on the child class? Emulating this query would
>> be either very inefficient and (for large datasets) possibly return no
>> results, at all, or require denormalization which I'd find funny in
>> the case of MTI because it brings us back to single-table inheritance,
>> but it might be the only solution that works efficiently on all NoSQL
>> DBs.
>>
>
> Filters on base fields can be implemented fairly easily on databases
> with IN queries. Otherwise I suppose it raises an exception.
How would that be implemented with an IN filter (you have two
different tables)? What would the (pseudo-)code look like?
Bye,
Waldemar Kornewald
--
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+u
Re: NoSQL Support for the ORM
On Thu, Apr 8, 2010 at 12:08 PM, Waldemar Kornewald wrote: >> No, we don't. People are desiging there data in ways that fit their >> datastore. If all people did was implement a relational model in >> userland code on top of non-relational databases then they'd really be >> missing the point. > > Then you're calling everyone a fool. :) What do you call a CouchDB or > Cassandra index mapping usernames to user pks? Its purpose it exactly > to do something that relational DBs provides out-of-the-box. You can't > deny that people do in fact manually maintain such indexes. I think there are two very different goals; maybe opposite, maybe complementary: A: use the _same_ ORM with NoSQL backends. then it's important to provide (almos) every capability of the current ORM, even if they have to be emulated when the backend doesn't provide it natively. B: create a new ORM-like facilty for NoSQL (lets call it ONoM). it would be used mostly the same as the ORM; but with different performance properties, and some capabilities missing, some others added, and some available but with 'emulation warnings'. but in the end, they should return queryset-like objects, that _must_ be usable by existing code that take querysets. IMHO, if the choice between these two isn't make clear and explicit at start, this kind of arguments won't end. -- Javier -- 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: NoSQL Support for the ORM
On Apr 8, 10:50 am, Javier Guerra Giraldez wrote: > A: use the _same_ ORM with NoSQL backends. then it's important to > provide (almos) every capability of the current ORM, even if they have > to be emulated when the backend doesn't provide it natively. To do this would mean to essentially implement a relational database on top of a non-relational data store. Except it would be worse, because instead of using the database's built-in logic, you'd be doing all of these operations over the network. It would also be very, very difficult to do this in a way where the abstraction wouldn't break down when doing anything non-trivial. It's just a bad idea. It's for these same reasons that some database backends throw errors for some of the aggregate operations. FWIW, I think Alex's approach has merit--only support that subset of features that the underlying database directly supports. If someone wants to build features on top of that, they can do so, but it should probably live externally to Django. At least until it becomes very stable and widely-used. Thanks, Eric Florenzano -- 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.
NoSQL Support for the ORM
On Thursday, April 8, 2010, flo...@gmail.com wrote: > On Apr 8, 10:50 am, Javier Guerra Giraldez wrote: > >> A: use the _same_ ORM with NoSQL backends. then it's important to >> provide (almos) every capability of the current ORM, even if they have >> to be emulated when the backend doesn't provide it natively. > > To do this would mean to essentially implement a relational database > on top of a non-relational data store. Except it would be worse, > because instead of using the database's built-in logic, you'd be doing > all of these operations over the network. It would also be very, very > difficult to do this in a way where the abstraction wouldn't break > down when doing anything non-trivial. What I'm proposing is not a complete emulation of all features at all cost, but simply an automation of the things that are possible and in wide use on nonrel DBs. Moreover, you'd only use these features where actually needed, so this would be a helper that replaces exactly the code you'd otherwise write by hand - nothing more. Denormalization, counters, etc. indeed go over the network, but people still do it because there is no alternative (CouchDB being an exception, but there we can auto-generate a view, so the index is created on the DB: same game, different location). I'm also not saying that this should be tightly integrated in Django. It's good enough to provide a separate package that adds these features. I'm just concerned that Alex' refactoring will make it more difficult or even impossible to implement an emulation layer because his goal is totally different. Bye, Waldemar Kornewald -- 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
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.
I've got questions that might help:
* how will views know about their current application?
* how will views get their app settings after your changes?
* is it a good idea to make urls properties (namespace, app_name)
correspond with the same application properties?
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'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!)
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.
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 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 ov
Re: NoSQL Support for the ORM
Hi Waldemar, Alex,
why you didn't do different threads for the different issues? :\
Regarding getting .filter() to work, I suggest we will use explicit
and implicit indexes, something like this:
class User(models.Model):
username = models.CharField(max_length=200, db_index=True) #
db_index=True should add the third line implicitly
email = models.CharField(max_length=200) # db_index=True can help,
but we have to go explicit here.
email = models.CharField(max_length=200, unique=True,
db_index='lowercase') # further ideas on lowercase support
#username_index = models.Index(['username'], 'pk') # line 3
email_index = models.Index(['email'], 'pk',
filter={'email':'lowercase'}) # line 4
...
And user will write:
users = User.objects.filter(email_index__startswith='me@')
Or:
class UsernameIndex(models.Index):
model = User
keys = ['category', 'email']
values = ['id']
def clean_email(value):
return value.lower()
and the user writing:
users = UsernameIndex.objects.filter(email__startswith='me@', category='staff')
But I don't think it has related to GSoC at all.
And this can be made outside of Django.
The same for Counters:
class User(models.Model):
username = models.CharField(max_length=200, db_index=True)
email = models.CharField(max_length=200)
category = models.CharField(max_length=20, choices=(('S', 'Staff'),
('U', 'User'))
counter = aggregates.Counter('category') # count number of users by category
I think, we should go with a separate Django proposal(s), don't put
that on Alex's shoulders.
What Alex will need to provide, is a way to assign a hook for
.filter() from QuerySet, which probably should be put into some kind
of NosqlManager (which will replace Manager at User.objects).
On Thu, Apr 8, 2010 at 8:08 PM, Waldemar Kornewald wrote:
> On Thu, Apr 8, 2010 at 6:14 PM, Alex Gaynor wrote:
>> On Wed, Apr 7, 2010 at 4:43 PM, Waldemar Kornewald
>> wrote:
>>> On Wed, Apr 7, 2010 at 5:12 PM, Alex Gaynor wrote:
No. I am vehemently opposed to attempting to extensively emulate the
features of a relational database in a non-relational one. People
talk about the "object relational" impedance mismatch, much less the
"object-relational non-relational" one. I have no interest in
attempting to support any attempts at emulating features that just
don't exist on the databases they're being emulated on.
>>>
>>> This decision has to be based on the actual needs of NoSQL developers.
>>> Did you actually work on non-trivial projects that needed
>>> denormalization and in-memory JOINs and manually maintained counters?
>>> I'm not making this up. The "dumb" key-value store API is not enough.
>>> People are manually writing lots of code for features that could be
>>> handled by an SQL emulation layer. Do we agree until here?
>>>
>>
>> No, we don't. People are desiging there data in ways that fit their
>> datastore. If all people did was implement a relational model in
>> userland code on top of non-relational databases then they'd really be
>> missing the point.
>
> Then you're calling everyone a fool. :) What do you call a CouchDB or
> Cassandra index mapping usernames to user pks? Its purpose it exactly
> to do something that relational DBs provides out-of-the-box. You can't
> deny that people do in fact manually maintain such indexes.
>
> So, you're suggestion to write code like this:
>
> # --
> class User(models.Model):
> username = models.CharField(max_length=200)
> email = models.CharField(max_length=200)
> ...
>
> class UsernameUser(models.Model):
> username = models.CharField(primary_key=True, max_length=200)
> user_id = models.IntegerField()
>
> class EmailUser(models.Model):
> email = models.CharField(primary_key=True, max_length=200)
> user_id = models.IntegerField()
>
> def add_user(username, email):
> user = User.objects.create(username=username, email=email)
> UsernameUser.objects.create(username=username, user_id=user.id)
> EmailUser.objects.create(email=email, user_id=user.id)
> return user
>
> def get_user_by_username(username):
> id = UsernameUser.objects.get(username=username).user_id
> return User.objects.get(id=id)
>
> def get_user_by_email(email):
> id = EmailUser.objects.get(email=email).user_id
> return User.objects.get(id=id)
>
> get_user_by_username('marcus')
> get_user_by_email('mar...@marcus.com')
> # --
>
> What I'm proposing allows you to just write this:
>
> # --
> class User(models.Model):
> username = models.CharField(max_length=200)
> email = models.CharField(max_length=200)
> ...
>
> User.objects.get(username='marcus')
> User.objects.get(email='mar...@marcus.com')
> # --
>
> Are you seriously saying that people should use the first version of
> the code when they work with a simplistic NoSQL DB (note, it's how
> they work today with those DBs)?
>
>>> * Django apps written for NoSQL will be portable across all N
Re: NoSQL Support for the ORM
On Apr 8, 12:32 pm, Waldemar Kornewald wrote: > What I'm proposing is not a complete emulation of all features at all > cost, but simply an automation of the things that are possible and in > wide use on nonrel DBs. Moreover, you'd only use these features where > actually needed, so this would be a helper that replaces exactly the > code you'd otherwise write by hand - nothing more. Denormalization, > counters, etc. indeed go over the network, but people still do it > because there is no alternative (CouchDB being an exception, but there > we can auto-generate a view, so the index is created on the DB: same > game, different location). "Denormalization, counters, etc." is a completely orthogonal problem. Solving those problems would help even those who are using relational databases, in fact. But just because it's useful, and precisely because it's orthogonal, means it doesn't belong in this summer of code project. I think what you're going to run into is that since CouchDB, Cassandra, MongoDB, GAE, Redis, Riak, Voldemort, etc. are all so vastly different, that attempting to do *any* emulation will result in serious pain down the line. It simply doesn't seem reasonable to claim that whatever refactoring Alex does, will make "it more difficult or even impossible to implement an emulation layer" because all he would be doing is decoupling SQL from the query class. That can *only* make your goal easier. Thanks, Eric Florenzano -- 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: Application Loading
On Apr 8, 5: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 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,
> }
> return direct_to_template(request, te
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 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
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.
[GSOC] Application to update the Test Suite
I've written an application to improve Django's Test Suite. http://code.djangoproject.com/wiki/SummerOfCode2010#Testingupdates My application is here (also pasted below for convenience): http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/paulmcmillan/t127077396156 I'm hoping for constructive feedback particularly in the area of maintaining test integrity. I realize this is a fairly late application, but the task itself is relatively non-controversial. Thanks! -Paul = The problem Django's testing suite has become fragmented over time. The modeltests and regressiontests directories serve similar purposes and should be joined. Nobody wants to do concerted work to improve testing because it isn't a showstopping bug or a new feature. GSOC provides an opportunity to support this kind of work. Proposal I will merge the code in modeltests and regressiontests, turning doctests into unit tests and cleaning up existing code as I go. I will use coverage.py to verify that the re-written tests cover the same areas of code as the previous ones did, as well as identifying areas without coverage. Many GSOC proposals are for large feature improvements that will involve a major code branch and merge. This project can instead be done as a series of incremental patches, reducing the impact of a failure to complete and providing more immediate results. In order to avoid introducing new bugs, I will configure a variety of virtual machines for testing. At a minimum, I will test in Ubuntu, Windows XP, and Mac OS X, with the most recent versions of Python 2.4, 2.5, and 2.6. On each of these systems, I will test against the supported database backends (PostgreSQL, MySQL, SQLite, Oracle). I will build scripts to automate the test running in these environments so that testing can continue prior to patches being merged to trunk. Since Django 1.2 is dropping support for Python 2.3, there is extra code in the test suite to support 2.3 that can be removed. This should improve the speed of test running. Internally, when a doctest is run, Python converts it into a unittest before actually executing it. It might be possible to use this code to automate the conversion. Converting to unittests should improve test run time because it eliminates the parsing necessary to convert each doctest into a unittest. The #python IRC channel anecdotally agrees on this point. Timeline Week 1: Configure test systems, build infrastructure to automate testing on these systems. Investigate code to automate conversion from doctests to unittests. Get coverage.py working and establish a baseline for what is covered. Week 2-10: There are 136 directories in modeltests and regressiontests. I will convert and clean up 15 directories per week. Some weeks will be harder than others, and I will spread out the especially labor intensive directories. Week 10-12: This is an overflow buffer if anything turns out to be unexpectedly time consuming. If it is not necessary, I can revert to more general code cleanup or bugfix tasks, particularly those related to performance profiling. I expect to devote 20-30 hours per week to the project. Some weeks I may have to devote more time if a particular set of tests are hard to convert. About you I'm a student at UC Berkeley entering my final undergraduate year in the Cognitive Science program. I successfully completed the 2008 Summer of Code for NESCENT, and currently work on a number of Django- powered projects for clients of my company. I contribute to StackOverflow, and enjoy photography. My Resume: http://careers.stackoverflow.com/paulmcmillan -- 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.
