Re: Django-nonrel patches

[Chris Northwood]

On 26 June 2012 22:07, Adam "Cezar" Jenkins  wrote:

> I have to agree, that's the big one. Though I the ecosystem of 3rd party
> apps is what makes using Django so great. If there is one ORM for  99% of
> the apps out there, and only one that works Mongo, then the only real use
> case of Django is going to be a system where you're using a RDBM
> in combination with Mongo.

Surely that's what it needs though, an 'ORM' and an 'Object-Document
Mapper' at some point. What's the advantage of trying to shoehorn
MongoDB to work with an ORM, when it's not relational, and as it has
to be hidden behind the same abstraction layer as a RDBMS, you lose
the benefits of it being non-relational?

Chris

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: GeoDjango and requirement's versions

[Chris Northwood]

On 28 May 2012 07:50, Volker Froehlich  wrote:
> Hello!
>
> https://docs.djangoproject.com/en/dev/ref/contrib/gis/install/#requirements 
> lists GeoDjango's version requirements.
>
> Fedora ships newer versions of those libraries. I was wondering whether
> any incompatibility could exist:

I've been using GeoDjango on my Fedora desktop with no issues

>
> I was also wondering about PostGIS 2.0, although there is no Fedora
> package yet.

I believe PostGIS 2.0 isn't supported yet:
https://code.djangoproject.com/ticket/16455

Chris

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Revisiting multiline tags

[Chris Northwood]

A +1 from me too, I've really felt the pain on this when doing i18n
templates, I understand the aesthetics, but the aesthetics of
obscenely long tags is also bad imo...

On 24 February 2012 09:23, Shawn Milochik  wrote:
> On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers  
> wrote:
>>
>> In the interest of making the wider community opinion heard, I too am +1 on 
>> this, my feeling is exactly the same as Stephen.
>>
>> --
>
> +1
>
> I understand that a BDFL has spoken and this change isn't going to
> happen. I hate to add to the noise, but since the argument from
> popularity fallacy has been invoked, I feel the need to point out that
> many of us didn't bother to weigh in because we didn't choose to add
> to the noise. Especially after the case was so well-made by others --
> it didn't seem necessary.
>
> Shawn
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Django application instances

[Chris Northwood]

Hi all,

I've been playing around this the branch on github for a while now,
but unfortunately me knowledge of Django's internals only goes so far
with regards to getting multiple instance support working fully,
particularly around how models work. I've got to the point where you
can now instantiate multiple copies of apps with distinct labels, and
these are registered in the cache:
https://github.com/cnorthwood/django/commit/52016c83b8794616b57c2296d23fb56e29a451a9

At present, this only registers one set of models and doesn't consider
the custom app_label

There are a few unanswered questions too:

* how would directly accessing a model work in a multi-instance
scenario? i.e., MyModel.objects.all() vs. get_model('my_app_instance',
'MyModel').objects.all()
* how would a view know which instance of an app it's supposed to be
responding to? One way may be to have the routing add an attribute to
the request object giving information about which app this set of URLs
belong to, i.e., put include(get_app('my_instance').urls) or similar
in the urlconf, and then when the view is called, it could perhaps
access the app object using request.app, or similar?

Thoughts?

Chris

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Django application instances

[Chris Northwood]

Hi all,

Thanks for the responses

On 6 November 2011 23:45, Russell Keith-Magee  wrote:
> Untrue -- #3591 has been the ticket tracking this idea for some time.
> The ticket even has a patch/branch that is just waiting for review.
> I've been wanting to do a review for some time, but life has conspired
> against me...

I've had a read through the ticket and I think I see the approach
being taken - would a view/model get the current app configuration by
then calling django.apps.find_app('my_app_label'), is that correct? If
so, I think that's problematic for multiple instances on the same
server, as my_app_label is hardcoded into the app.

The approach we took is to have the app_label defined in the
settings.py file in the instantiation of the app, so you can
instantiate the same app twice, but with two different labels (and
configs). The application framework then took the urlconf module for
that app, instantiated every view (which for us are class-based) and
then attached a "conf" object to it which the views could use to
access their configuration. The root urlconf then needed to use the
urlconf objects attached to the application instance, rather than the
"raw" urlconf in the includes in order to get this to work. Multiple
app instances is then fairly straight forward from this point.

A more generic way that could be used is to perhaps use the extra
kwargs feature of the urlconf to pass in a new kwarg to the view
(perhaps called _conf) which has the instance of that application's
configuration which can be accessed by views as they please.

> The focus of this branch has been to turn an "Application" into a
> configurable object; this would allow app designers to define
> configuration points that are set at time of deployment.
>
> The one major aspect that you've described but isn't covered by the
> current patch on #3591, is the idea of having multiple instance of the
> same app in a single project. This introduces the complication that
> database table names need to include a deploy-time component (i.e.,
> some sort of instance identifier), which, IIRC, was punted from the
> goal list for the SoC project that yielded this patch.  However, to
> the best of my knowledge, the approach described in the current patch
> *could* be used to handle the multiple instance scenario; it just
> hasn't been implemented.

We implemented this in a possibly non-elegant way, with our models
being naive, and our controllers doing queries based on the local_name
attribute (equivalent to the app_label).

Chris

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

Django application instances

[Chris Northwood]

Hi there,

My name's Chris Northwood and I'm a core contributor to the Molly
Project (http://mollyproject.org/), which is a mobile portal framework
built on top of Django. We're an open source project but we currently
think we're doing quite a few things that are "non-core" for us, and
we'd like to push back upstream into the Django project.

One of these things are multiple application instances. We've built a
fairly straight-forward way to instantiate multiple instances of the
same app (with self-contained configuration) in the settings.py, e.g.,

APPLICATIONS = [

Application('molly.apps.weather', 'oxweather', 'Oxford Weather',
location_id = 'bbc/25',
provider =
Provider('molly.apps.weather.providers.BBCWeatherProvider',
location_id = 25,
),
),

Application('molly.apps.weather', 'lonweather', 'London Weather',
location_id = 'bbc/8',
provider =
Provider('molly.apps.weather.providers.BBCWeatherProvider',
location_id = 8,
),
),

]

INSTALLED_APPS += extract_installed_apps(APPLICATIONS)
ROOT_URLCONF = 'molly.urls'

This defines two apps of the molly.apps.weather reusable Django app,
one with a URLconf under /oxweather/ and one under /lonweather/.
Depending on the URL accessed, the (class-based) views inside the app
then have access to a self.conf attribute which they can use when
querying the database (or whatever) to deliver different behaviour
based on the class, i.e., inside our view

current_weather =
Weather.objects.get(location_id=self.conf.location_id)

We use this fairly extensively, and there are a number of non-trivial
examples in our codebase too.

The URLconf is automatically generated by the molly.urls module, and
we also have the ability to annotate our class-based views using a
custom @url annotator so the URLconf for the application is also
automatically generated (to us it makes sense to keep the patterns in
the same place as the view!)

My question is, would the Django community at large find this
functionality useful, i.e., is it worth us working to break this
functionality out of our libraries and then provide a patch to you
guys? It's certainly non-trivial, and I wouldn't want to waste effort,
and I think this is functionality that could be useful for others.

Regards,

Chris Northwood

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.