Re: four NoSQL backends you want? :)

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

Re: four NoSQL backends you want? :)

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

Changes to LazySettings

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

Re: four NoSQL backends you want? :)

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

Re: four NoSQL backends you want? :)

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

Re: #12012 Logging: request for comments

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

Re: #12012 Logging: request for comments

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

Re: four NoSQL backends you want? :)

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

Re: Class based models

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

Re: #12012 Logging: request for comments

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

Re: dates postgres django trunk

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"

feature request: insensitive 'in'?

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

Re: dates postgres django trunk

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

Re: four NoSQL backends you want? :)

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

dates postgres django trunk

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

Re: proposal for lazy foreignkeys

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

Re: proposal for lazy foreignkeys

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

Re: proposal for lazy foreignkeys

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

Re: #12012 Logging: request for comments

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

Re: Application, tempaltetags and namespace

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

Re: Application, tempaltetags and namespace

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

Re: 'User' object has no attribute 'backend' - issue with using auth.login()

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

Re: Class based models

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

Re: proposal for lazy foreignkeys

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

Re: 'User' object has no attribute 'backend' - issue with using auth.login()

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,

Re: Proposal: Meta.required_together

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

Re: Proposal: Meta.required_together

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

Re: Proposal: Meta.required_together

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

Re: Proposal: Meta.required_together

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

Re: #12012 Logging: request for comments

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

Re: Proposal: Meta.required_together

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

Re: #12012 Logging: request for comments

On Sep 25, 7:46 pm, Antoni Aloy wrote: > > One last doubt, perhaps offtopic I have read logging module is slow, > good enough for 90% of applications but for the rest. Actually is > enough for me, but I can't see  to deal with log on big systems > Hi, If you are

Re: Application, tempaltetags and namespace

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 myself. > > Imagine you have an application called > >