On Jan 31, 8:27 pm, Carl Meyer wrote:
> On Jan 31, 1:49 am, Xavier Ordoquy wrote:
>
> > The thread is pretty long because there are also 2 threads in one:
> > - one for simply changing the site_id per request
> > - one for changing the all setting per request
>
> Exactly!
I've not supported a
On Jan 31, 1:49 am, Xavier Ordoquy wrote:
> The thread is pretty long because there are also 2 threads in one:
> - one for simply changing the site_id per request
> - one for changing the all setting per request
Exactly!
For the record, as far as I'm concerned #15089 is limited in scope to
the
On Jan 31, 8:30 am, James Hancock wrote:
> This post is getting pretty long. But I had a simple Django fix that would
> make it work a lot easier for me, and might help others. (I say this because
> of how I implemented it, I am working with about 60 different sites and it
> is a pretty simple arr
Le 31 janv. 2011 à 07:30, James Hancock a écrit :
> This post is getting pretty long. But I had a simple Django fix that would
> make it work a lot easier for me, and might help others. (I say this because
> of how I implemented it, I am working with about 60 different sites and it is
> a pret
This post is getting pretty long. But I had a simple Django fix that would
make it work a lot easier for me, and might help others. (I say this because
of how I implemented it, I am working with about 60 different sites and it
is a pretty simple arrangement)
Imagine you were able to set a site_id
I believe this ticket: http://code.djangoproject.com/ticket/14628
which was created during this chat session
http://www.revsys.com/officehours/2010/nov/05/#question5
is also relevant to the issue at hand.
An interesting bit of that chat is:
jacobkmnicoechaniz: one hint is that although the docu
Notice that I never suggested *django* to implement thread local hack,
it just allowes me to continue. The thread local hack is just that
hack, it hides the real problem for now since Django does not support
the stuff I need it to.
Settings object should be considered mainly read-only, if the stu
On Sun, Jan 30, 2011 at 2:20 AM, Russell Keith-Magee
wrote:
>
> Every single problem associated with using global variables exists
> with threadlocals -- and then a few more. They *can* be used
> successfully. However, in almost every case, they can also be avoided
> entirely with a good dose of r
In above I have error:
authbackend.save(session, user) -> bool
authbackend.load(session) -> user object
should be:
authbackend.save(request, user) -> bool
authbackend.load(request) -> user object
Since getting site id from request is the thing I need to do and save
it to session.
--
Y
With globals:
No patches to Django required. Flatpages, media urls, media roots can
be customed by request and works without single problem. Mostly
because settings are used like settings.SITE_ID etc. and not like
getattr(settings, 'SITE_ID') in apps.
If Django ever is patched to work without thi
On Jan 30, 7:20 am, Russell Keith-Magee
wrote:
> On Sat, Jan 29, 2011 at 8:55 PM, Jari Pennanen
> wrote:
> If an engineer came to their supervisor with a problem and said "I'm
> going to fix this problem with a global variable", they would be
> soundly beaten by any supervisor worth their salt
On Sat, Jan 29, 2011 at 8:55 PM, Jari Pennanen wrote:
> Certainly something new for me.
>
> That does look like a rather cool. Essentially if that works one could
> save even the request object to thread "global" and it would be
> accessible anywhere.
... and this is one of the biggest reasons wh
Hi!
I suggest you to look on to this _patch_setattr I cooked. I noticed
that it is also necessary to patch the __setattr__ of the settings
object in order to allow changes to the settings.SITE_ID again.
Following test would fail after TLSProperty:
settings.SITE_ID = 42
assert settings.SITE_ID ==
Sorry about second post but I'm so thrilled about this thread local
approach! Thanks Waldemar.
This changes everything, EVERYTHING.
I can just do:
settings.__class__.SITE_ID = make_tls_property()
settings.__class__.MEDIA_URL = make_tls_property()
settings.__class__.MEDIA_ROOT = make_tls_property
Certainly something new for me.
That does look like a rather cool. Essentially if that works one could
save even the request object to thread "global" and it would be
accessible anywhere.
It would solve many problems, such as django's authentication
middleware's shortcoming where it does not pass
Hi,
it's possible to manipulate the settings object in a thread-safe way. Here's
our dynamic site middleware:
https://bitbucket.org/wkornewald/djangotoolbox/src/535feb981c50/djangotoolbox/sites/dynamicsite.py
https://bitbucket.org/wkornewald/djangotoolbox/src/535feb981c50/djangotoolbox/utils.py
A
Graham is correct.
I pointed out this in my reply to reviewboard method which works just
like Jjdelc proposed, and that is incorrect way.
So simply put: Changing settings object in middelwares is WRONG. If
one changes the settings object before or after request, it will be in
intermediate state i
On Friday, January 28, 2011 6:59:43 PM UTC+11, James Hancock wrote:
>
> I have one question about changing the site ID per request.
> I assume that settings is imported from conf, and so in the end it is
> simply changing the same SITE_ID to fit the current request Django is
> handling.
>
> Do
I have one question about changing the site ID per request.
I assume that settings is imported from conf, and so in the end it is simply
changing the same SITE_ID to fit the current request Django is handling.
Does this ever become a problem? I am setting up around 250 sites for
example. If the si
If all you need to change is the SITE_ID on the settings file, using
different files for each is not only a mess to handle, but also means
that you'll spend extra RAM for each instance running.
I solve this by using a middleware that changes the SITE_ID based on
the request's hostname:
SITES_DICT
On Friday, January 28, 2011 2:09:06 AM UTC+11, Tom Evans wrote:
>
> On Wed, Jan 26, 2011 at 6:18 PM, Jari Pennanen
> wrote:
> > On Jan 26, 6:56 pm, FeatherDark wrote:
> >> Greetings huge django developer list,
> >> I just wanted to mention, this method totally works for me, I call it
> >> "Ski
Scrub my above message, here is the new revised and working summary
for per site login:
1. user_logged_in signal callback that adds
request.session[SITE_ID_SESSION_KEY] = request.site_id
2. AuthenticationForm with clean that does authenticate(site_id,
username, password)
3. MultiSitedAuthenticatio
I think I've found the necessary tools making the Django login to work
per site basis:
1. Create own login view that calls the auth backend with
authenticate(site_id, username, password)
2. Create own auth backend that takes site_id, username and password
(also checks permissions by site)
3. *)
On Wed, Jan 26, 2011 at 6:18 PM, Jari Pennanen wrote:
> On Jan 26, 6:56 pm, FeatherDark wrote:
>> Greetings huge django developer list,
>> I just wanted to mention, this method totally works for me, I call it
>> "Skinning"
>>
>> In the templates folder I have a file called "base.html'
>> Inside t
On Jan 26, 6:56 pm, FeatherDark wrote:
> Greetings huge django developer list,
> I just wanted to mention, this method totally works for me, I call it
> "Skinning"
>
> In the templates folder I have a file called "base.html'
> Inside that file is only 1 line:
> {% extends request.META.HTTP_HOST|cu
Greetings huge django developer list,
I just wanted to mention, this method totally works for me, I call it
"Skinning"
In the templates folder I have a file called "base.html'
Inside that file is only 1 line:
{% extends request.META.HTTP_HOST|cut:':'|add:'.html'%}
The rest of that same folder con
On Jan 26, 5:20 pm, Xavier Ordoquy wrote:
> Given the title, I would feel bad for the sysadmin if there was hundreds of
> setting files with just the site id within ;)
Ha, single file per site :) I would change to that any day.
The current system in place is following: ~60 (and growing) website
For the project which I plan to use this is such that all sites could
share same INSTALLED_APPS, but it would be truly awesome if full
settings were possible for each site.
On Jan 26, 5:10 pm, Lorenzo Gil Sanchez
wrote:
> I suggest to have a look to www.reviewboard.org since they have solved
> th
2011/1/25 Jari Pennanen :
> Hi!
>
> I'm on a monumental task here, I've decided to get one Django instance
> running hundreds of websites.
>
> I've run in to couple of shortcomings with django:
>
> 1. Global SITE_ID does not work since some requests belong to
> different site. I've created middlewa
Given the title, I would feel bad for the sysadmin if there was hundreds of
setting files with just the site id within ;)
As for the urlconf, it's already possible. core/urlresolvers have a set/get
urlconf that is set for the thread by the BaseHandler.
Don't get me wrong, I started some work in
> On the other hand, having one setting file per site where the only difference
> is the site id seems a bit too much overhead.
Why not use something like this:
from global_settings import *
SITE_ID = 235
#This also allows further changes like:
#INSTALLED_APPS = INSTALLED_APPS + (
# 'fooapp
Hi there,
I also started to have a look at something similar (ie, with settings for each
site).
The proposal made in the ticket wouldn't fit what you are trying to do.
The current idea is to have the site id depends on the request but assumes to
have only one common settings file.
On the other
On Jan 25, 4:56 pm, Jari Pennanen wrote:
> I'm on a monumental task here, I've decided to get one Django instance
> running hundreds of websites.
I'm also on similar path here. I'm trying to build a system where
django instances running on several servers are serving hundreds of
websites. Each we
I am also trying to achieve something highly similar to this but in a
dilemma, for how to proceed. I have written a post about this:
http://www.rohanjain.in/blog/hosting-multiple-sites-with-same-django-project/.
Is there any existing big project following a similar concept?
--
You received thi
On Wednesday, January 26, 2011 2:27:31 AM UTC+11, Russell Keith-Magee wrote:
>
> 2011/1/25 Łukasz Rekucki :
> > On 25 January 2011 16:15, Russell Keith-Magee
> wrote:
> >>
> >> For the next couple of weeks the core developers will be a little busy
> >> finalizing the 1.4 release;
> >
> > That i
On Tue, Jan 25, 2011 at 3:45 PM, Graham Dumpleton
wrote:
> Since the 'futures' module is only a part of Python 3.2, that must mean you
> are using that and thus have ported Django to Python 3 already. When can we
> expect that then. ;-)
So, here's what happened.
You all may remember that some ti
On Wednesday, January 26, 2011 2:27:31 AM UTC+11, Russell Keith-Magee wrote:
>
> 2011/1/25 Łukasz Rekucki :
> > On 25 January 2011 16:15, Russell Keith-Magee
> wrote:
> >>
> >> For the next couple of weeks the core developers will be a little busy
> >> finalizing the 1.4 release;
> >
> > That i
2011/1/25 Łukasz Rekucki :
> On 25 January 2011 16:15, Russell Keith-Magee wrote:
>>
>> For the next couple of weeks the core developers will be a little busy
>> finalizing the 1.4 release;
>
> That is obviously supposed to be 1.3 ;)
Erm... ahh... No... I'm writing from the FUTURE!!! The flying c
On 25 January 2011 16:15, Russell Keith-Magee wrote:
>
> For the next couple of weeks the core developers will be a little busy
> finalizing the 1.4 release;
That is obviously supposed to be 1.3 ;)
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
On Tue, Jan 25, 2011 at 10:56 PM, Jari Pennanen wrote:
> Hi!
>
> I'm on a monumental task here, I've decided to get one Django instance
> running hundreds of websites.
>
> I've run in to couple of shortcomings with django:
>
> 1. Global SITE_ID does not work since some requests belong to
> differe
Hi!
I'm on a monumental task here, I've decided to get one Django instance
running hundreds of websites.
I've run in to couple of shortcomings with django:
1. Global SITE_ID does not work since some requests belong to
different site. I've created middleware that adds request.site_id
based on hos
41 matches
Mail list logo
