On Tue, Sep 28, 2010 at 8:31 AM, David P. Novakovic
wrote:
> This has probably been discussed at great length previously... but my
> 2c follows:
>
> If you are using a column/doc store you are trying to solve a
> different problem than if you are using an SQL db.
>
> How important is 100% interop?
On Tue, Sep 28, 2010 at 07:22:11AM +0800, Russell Keith-Magee wrote:
> On Tue, Sep 28, 2010 at 1:51 AM, Mark Bucciarelli wrote:
> >
> > I guess the test suite must not cover all the basees, making it a
> > necessary but not sufficient criteria for inclusion?
> >
>
> The problem is that NoSQL stor
Hi all,
Ticket #14297 [1] suggests changes to LazySettings for performance
improvements. The best solution AFAIC is that __getattr__ triggers a
setup routine on first access, which loads *all* the settings into the
LazySetting object itself. This eliminates the __getattr__ overhead for
all subse
On Mon, Sep 27, 2010 at 7:22 PM, Russell Keith-Magee
wrote:
> On Tue, Sep 28, 2010 at 1:51 AM, Mark Bucciarelli wrote:
>> On Sat, Sep 25, 2010 at 10:21:06PM +0800, Russell Keith-Magee wrote:
>>>
>>> The number 4 wasn't actually the important bit - it was that I want
>>> to see a range of noSQL ap
This has probably been discussed at great length previously... but my
2c follows:
If you are using a column/doc store you are trying to solve a
different problem than if you are using an SQL db.
How important is 100% interop? Surely it's about documenting the
differences between them and providin
On Sat, 2010-09-25 at 14:16 +0800, Russell Keith-Magee wrote:
> So - have at it. I'm really excited by this; so let me know everywhere
> I've messed up so that we can get this into trunk.
Sorry, missed this before. A couple of comments...
Logging config as last stage of settings loading is wher
On Mon, Sep 27, 2010 at 11:16 PM, Luke Plant wrote:
> Hi Russell,
>
> On Sat, 2010-09-25 at 14:16 +0800, Russell Keith-Magee wrote:
>
>> At this point, I'm calling for feedback, particularly on the following:
>>
>> * logging config as the last stage of settings loading. Is this the
>> right place
On Tue, Sep 28, 2010 at 1:51 AM, Mark Bucciarelli wrote:
> On Sat, Sep 25, 2010 at 10:21:06PM +0800, Russell Keith-Magee wrote:
>>
>> The number 4 wasn't actually the important bit - it was that I want
>> to see a range of noSQL approaches represented. I don't want to see
>> 4 key-value stores; I
There's a quite a few things that I don't like about the get_model
approach. I'll focus on one though: contrib.comment's own models do
not respect it.
Consider a customized model for comments (the model MyComment in
my_comments)
so in settings.py we put:
COMMENTS_APP = 'my_comments'
then we do th
On 27 September 2010 17:16, Luke Plant wrote:
> Anyway, this seems good to me, and I can't think of a better place. For
> the probably rare case of putting logging calls in your settings.py
> (like Hanne Moa does), there is nothing to stop you setting up logging
> yourself inside settings.py, whi
DOH, I thought I tried changing the DATE_FORMAT and it had no effect.
Seems I checked the wrong server when I checked that.
Thanks, it does fix it when you compare output on the right server.
8-|
--
You received this message because you are subscribed to the Google Groups
"Django developers" gr
I understand that there's a workaround using iregex (http://
stackoverflow.com/questions/2667524/django-query-case-insensitive-list-
match), but an 'iin' seems like it would be a nice feature to have in
the query syntax.
--
You received this message because you are subscribed to the Google Groups
I thought that's what get_model did?
You specify your own comments app and register your own (subclass or
other) model within that function and its used throughout the original
app.
On Sep 27, 3:02 am, Klaas van Schelven
wrote:
> On Sep 27, 4:17 am, "subs...@gmail.com" wrote:
>
> > I may be den
Thank you for your email.
This is not a bug in Django, it is the correct output when you set
DATE_FORMAT = "%m/%d/%Y". Your desired output will come if you set
DATE_FORMAT = 'm/d/Y'.
The documentation [1] may not be too clear on what formatting is
required, but does give an example which hints at
On Sat, Sep 25, 2010 at 10:21:06PM +0800, Russell Keith-Magee wrote:
>
> The number 4 wasn't actually the important bit - it was that I want
> to see a range of noSQL approaches represented. I don't want to see
> 4 key-value stores; I want to see a key-value store, and a document
> store, and a col
Recently updated to the latest trunk (couple weeks ago now).
I think this may be a bug in the current trunk.
alist = Table_with_date_column.objects.all()
in template:
{{ alist.date_field }}
renders:
%10/%26/%2009
%07/%22/%2009
...
This must have something to do with the
settings.py
DA
On Mon, Sep 27, 2010 at 5:46 PM, Luke Plant wrote:
> On Mon, 2010-09-27 at 11:36 +0200, Patryk Zawadzki wrote:
>> With the risk of being ignored once again, I dare to link to a working
>> solution that does not need any changed to the framework itself (other
>> than perhaps including the factory c
On Mon, 2010-09-27 at 16:46 +0100, Luke Plant wrote:
> Some notes:
> 1) it seems like line 15 in abstract.py should say 'abstract':'False',
> not 'True' - did I miss something?
Cancel that one, I was missing the fact that we are still inheriting
from the generated class, not doing:
MyCategory
On Mon, 2010-09-27 at 11:36 +0200, Patryk Zawadzki wrote:
>
> With the risk of being ignored once again, I dare to link to a working
> solution that does not need any changed to the framework itself (other
> than perhaps including the factory class):
>
> http://gist.github.com/584106
This looks
Hi Russell,
On Sat, 2010-09-25 at 14:16 +0800, Russell Keith-Magee wrote:
> At this point, I'm calling for feedback, particularly on the following:
>
> * logging config as the last stage of settings loading. Is this the
> right place? Can anyone think of a better place?
In the context of runni
On Mon, Sep 27, 2010 at 3:14 AM, Russell Keith-Magee
wrote:
> On Mon, Sep 27, 2010 at 1:43 PM, Mathieu Leduc-Hamel
> wrote:
>> Hi all,
>>
>> I'm curious to know if it's planned in the future to force the use of
>> the complete name of the applications and the templatestags. I'll
>> explain mysel
Cody Soyland has also done some work on this in a reusable app, which might
be useful as a starting point:
http://github.com/codysoyland/django-smart-load-tag
Cheers,
Eric
--
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com
--
You received this message
On Sat, Sep 25, 2010 at 11:13 AM, Harro wrote:
> Authentication = verification
> Login = saving the authenticated user so we remember them.
>
> Putting login on the user model is a bad idea.
> That will only make the whole auth app less flexible than it already
> is.
> What if I have another model
On Sep 27, 4:17 am, "subs...@gmail.com" wrote:
> I may be dense but is this the functional equiv of cobtrib.comments
> get_model()?
Nope.
Rather, it's a way to subclass models that are provided by reusable
apps, and letting the reusable app use the subclassed instance
throughout.
>
> On Sep 26
On Sun, Sep 26, 2010 at 8:10 AM, Russell Keith-Magee
wrote:
> My biggest technical concern is the same as Alex's -- that it doesn't
> address the 'FK to multiple models' problem. While I agree with your
> 'no silver bullet' response to Alex, I also don't want to end up with
> two (or more) complet
I hope I understand your problem correctly, but authentication is
handled by your authentication backend, not your model. Your backend
can return anything you like (eg Foo) and that is what you'll get when
you call authenticate(). This object is given a .backend attribute by
django.contrib.auth, w
Thanks, David. I've read some about the "Custom validation error on
unique_together" ticket. I imagine that if people want customization
there, required_together would need the same. The only idea I have
that seems to work for both situations is:
required_together = (('weight', 'height', 'You must
On Sep 27, 9:22 am, "David P. Novakovic"
wrote:
> Is it? I read this as different to anything in the ORM.
Well either way; he could have been more specific which stuff he is
talking about (remember the only classes having Meta are Modelform and
Model -- at least does are the two where I use it o
Is it? I read this as different to anything in the ORM.
This is about conditionally requiring a second field if one is filled
out. Normally it would be done at the JS level.
I think it's a good idea, assuming I haven't missed something that
already does this.
I can't help thinking this is part o
This is a feature request. I'm not asking how to do it. If you read,
I've shown the current method of doing this in clean(). I'm proposing
the addition of an additional Meta option to allow for automatically
adding this behavior.
On Sep 27, 1:18 am, Florian Apolloner wrote:
> Please post usage qu
On Sep 27, 1:15 am, Russell Keith-Magee
wrote:
>
> On top of that, there is the purely architectural argument:
> threadlocals are a global variable by any other name. They increase
> coupling in the systems in which they are used. If an engineer came to
> you and proposed a design that relied upo
Please post usage questions to the users list. This is already doable
with model validation.
Florian
--
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 fr
32 matches
Mail list logo