2010/1/20 Jacob Kaplan-Moss :
> On Wed, Jan 20, 2010 at 12:31 PM, Luke Plant wrote:
>> I don't understand how avoiding the settings.py mechanism will produce
>> *more* flexibility.
>
> The problem -- at least as I see it -- is that of a intertwingulment
> of "application" settings with "ops" setti
2010/1/21 Russell Keith-Magee :
>
> It strikes me that this is just one example of a whole class of "best
> practice" stuff that we should document, but don't at present - like
> project layout, automated deployment, continuous integration,
> configuration management, etc.
>
> We've historically av
On 01/21/2010 01:31 AM, Ian Kelly wrote:
> 2010/1/20 Łukasz Rekucki :
>> 2010/1/21 Jerome Leclanche :
>>> Hi Lukasz, thanks for the wrap up
>>>
>>> Main issue is precision. I personally very, very often work with
>>> milliseconds, and I can imagine many use cases where I'd need to work
>>> with mic
Hi Russell,
Thanks, I'm rather happy too.
It's exactly what we wanted!
DB Routing API is even better than some fixed db routing format.
I just thought about any model with GFK, like TagField from django-tagging --
with multidb, to be effectively reusable, it has to know in what DB
to save and loa
On Thu, Jan 21, 2010 at 8:21 PM, Yuri Baburov wrote:
> Hi Russell,
>
> Thanks, I'm rather happy too.
> It's exactly what we wanted!
>
> DB Routing API is even better than some fixed db routing format.
> I just thought about any model with GFK, like TagField from django-tagging --
> with multidb, t
On 01/21/2010 01:31 AM, Ian Kelly wrote:
> In other words, all the same limitations that we already handle for
> TimeFields. This looks to me like a green light to just use the
> native datatypes.
I wrote a simple DurationField for my own purpose, it is not meant to be
included in Django as-is,
Russell Keith-Magee wrote:
class MasterSlaveRouter(object):
def db_for_read(self, model, db=None):
# Point all read operations to a random slave
return random.choice(['slave1','slave2'])
def db_for_write(self, model, db=None):
# Point all write operations to the m
On Tuesday 19 January 2010 21:26:17 Jacob Kaplan-Moss wrote:
> So there we are. This is very much a brain dump, and I don't really
> expect any concrete action to result from it. However, I found some
> really interesting stuff there, and I thought I'd share.
Thanks for your clarification elsewhe
On Jan 21, 2010, at 9:58 AM, Luke Plant wrote:
> On Tuesday 19 January 2010 21:26:17 Jacob Kaplan-Moss wrote:
>
>> So there we are. This is very much a brain dump, and I don't really
>> expect any concrete action to result from it. However, I found some
>> really interesting stuff there, and I t
> I would have guessed that a big issue with Django from an enterprise
> perspective is its use of 'singletons'.
>
> How much is this an issue in practice?
Yes, that's been my experience. For complex deployments with tens or
hundreds of apps, it is often the case that it is absolutely essential
t
On Thu, Jan 21, 2010 at 8:58 AM, Luke Plant wrote:
> I would have guessed that a big issue with Django from an enterprise
> perspective is its use of 'singletons'.
[snip]
> How much is this an issue in practice?
Other than databases, it hasn't been much of an issue with most of the
BigCos I've be
On Thu, Jan 21, 2010 at 10:24 AM, sago wrote:
> Case studies are helpful if folks can share them.
Just a quick note that the DSF is working on gathering case studies;
getting folks who have permission to share is indeed a tricky issue.
Not much is set up yet, but I, at least, would be *thrilled*
I agree that managing settings gets to be a bit difficult in many
environments - even non Fortune 1000 environments. One of the things
we've played with in Satchmo is a database backed solution that allows
you to define reasonable defaults - even override-able in the settings
- but allow people to
Hi!
My previous experience was from Java J2EE world and as Jacob said we
adopted Django because it really shines solving some complexity
problems associated to J2EE world as MVC patter, templates, etc., but
I agree that a common way to configure external applications would be
nice.
I'll also have
One of my favourite errors in Python is this one:
File "settings.py", line 2
SyntaxError: Non-ASCII character '\xce' in file settings.py on line 2,
but no encoding declared; see http://www.python.org/peps/pep-0263.html
for details
This is when you've declared a non-ASCII
On Wed, Jan 20, 2010 at 11:06 AM, Russell Keith-Magee
wrote:
> I've just uploaded a new patch improving the multi-db interface. This
> patch introduces a way to easily configure the database selection
> process, and enables you to assign a database selection mechanism to
> models not under your co
On 2010-01-21, at 9:15 AM, chris.moff...@gmail.com wrote:
> I agree that managing settings gets to be a bit difficult in many
> environments - even non Fortune 1000 environments. One of the things
> we've played with in Satchmo is a database backed solution that allows
> you to define reasonable de
Hi Russell,
On Thu, Jan 21, 2010 at 7:10 PM, Russell Keith-Magee
wrote:
> On Thu, Jan 21, 2010 at 8:21 PM, Yuri Baburov wrote:
>> Hi Russell,
>>
>> Thanks, I'm rather happy too.
>> It's exactly what we wanted!
>>
>> DB Routing API is even better than some fixed db routing format.
>> I just thoug
On Fri, Jan 22, 2010 at 1:35 AM, Andy McKay wrote:
> One of my favourite errors in Python is this one:
>
> File "settings.py", line 2
> SyntaxError: Non-ASCII character '\xce' in file settings.py on line 2,
> but no encoding declared; see http://www.python.org/peps/pep-0263.ht
On Fri, Jan 22, 2010 at 2:03 AM, Yuri Baburov wrote:
> Hi Russell,
>
> On Thu, Jan 21, 2010 at 7:10 PM, Russell Keith-Magee
> wrote:
>> Secondly, while I can see how this information could be useful, it
>> doesn't change the fact that the information is just as easy to manage
>> manually. Syncdb
On Thu, Jan 21, 2010 at 9:54 PM, Ivan Sagalaev
wrote:
> Russell Keith-Magee wrote:
>>
>> class MasterSlaveRouter(object):
>> def db_for_read(self, model, db=None):
>> # Point all read operations to a random slave
>> return random.choice(['slave1','slave2'])
>>
>> def db_for_wri
Hey guys-
I've been using Django 1.2's new messages framework a lot lately, and
it's awesome. but, i think I may have discovered a bug (or possibly
I'm doing something wrong, but if so, I sure as hell can't figure out
what it is). It seems to me the messages are never delivered to the
user when th
After a little more playing around, I've discovered that this is not
an issue if I use the session storage -- so it seems to be related to
cookie storage.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
I wonder if this is related?
http://groups.google.com/group/django-developers/browse_thread/thread/5613e9a03d92c902/738a3b81e405dc78#738a3b81e405dc78
On Jan 21, 2010, at 10:55 PM, j...@jeffcroft.com wrote:
> After a little more playing around, I've discovered that this is not
> an issue if I use
Sean-
Can't say for sure it's related, but I can verify that I was using
Safari (Mobile) and that my message had commas in them...so it
definitely could be.
Switching to session storage solved the problem for me, and that
backend works fine for my needs. So, it's no longer pressing issue
for me,
25 matches
Mail list logo
