Re: four NoSQL backends you want? :)

[Russell Keith-Magee]

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? Surely it's about documenting the
> differences between them and providing an interface to document stores
> that isn't completely foreign to people who know how to use the django
> ORM?

Sounds like you need to watch the couple of panel discussions at
DjangoCon.us and DjangoCon.eu where we discuss this exact point. :-)

100% interop with a relational store is a pipe dream. As you say,
they're different solutions for different problems. NoSQL support in
Django isn't about trying to make everything look like a hammer. Its
about ensuring that all the tools we have in the shed are compatible.

So - the real goal is to ensure that you can use forms and generic
views with NoSQL stores, not to ensure that you take an app built
using a relational store, and deploy it on a NoSQL store. Using a
common query interface is the easiest way to make this happen; and as
a bonus, it means that NoSQL stores gain a query interface that is
familiar.

> In which case it seems that the trust issue Russ was talking about
> earlier is the main barrier here. We need more trusted people to be
> using the non-rel code.

To be sure - this is a big barrier. The more eyeballs this code gets,
the better the end product will be.

Yours,
Russ Magee %-)

-- 
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 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: four NoSQL backends you want? :)

[Mark Bucciarelli]

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 stores don't necessarily have feature parity
> with relational databases. 
>

For MonetDB, this is not an issue as they provide a SQL wrapper.

For the other No-SQL backends, is it feasible to specify the subset of
tests they must pass to be acceptable?

And if you define that unsupported operations should throw a particular
kind exception, you wouldn't need annotation sugar; the test logic can
branch based on what features the DB says it supports.

m

-- 
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 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.

Changes to LazySettings

[Luke Plant]

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 subsequent retrieval of settings (apart from when the setting
doesn't exist, in which case you still get a __getattr__ call).

This should be a fully backwards compatible change.  There were some
test failures, but these were all caused by test code relying on the
internal implementation of LazySettings, i.e. the '_wrapped' object
attribute (when in fact there was no need to do this after r11824 [2]) 

But can anyone else think of any gotchas with this change before I
commit it? It produces a 30% improvement for the benchmark that relates
to the ticket [3].

Thanks,

Luke


[1] http://code.djangoproject.com/ticket/14297
[2] http://code.djangoproject.com/changeset/11824
[3]
http://github.com/spookylukey/djangobench/tree/master/djangobench/benchmarks/l10n_render/

-- 
"Christ Jesus came in to the world to save sinners" (1 Timothy 1:15)

Luke Plant || http://lukeplant.me.uk/


-- 
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 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: four NoSQL backends you want? :)

[Alex Gaynor]

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 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 column store, etc. I need to see that the API is rich
>>> enough to cover all noSQL bases.
>>>
>>
>> I've seen references to Django's test suite on this list in the past,
>> and I'm curious why the criteria can't simple be: "a clean run on our
>> test suite."
>>
>> I have a backend [1] for MonetDB (a column store DB).  They expose a SQL
>> wrapper around their non-SQL engine, which makes it pretty easy to
>> support.
>>
>> On my todo list was to see how it fares with the Django test-suite.
>> I guess the test suite must not cover all the basees, making it a
>> necessary but not sufficient criteria for inclusion?
>>
>> Correct?
>
> Well, sort of.
>
> The problem is that NoSQL stores don't necessarily have feature parity
> with relational databases. For example, the concept of a join is
> pretty fuzzy when it comes to stores like MongoDB and GAE. You *could*
> emulate join with a series of lookups, but that could get pretty
> spectacularly inefficient, so we're not going to force stores to
> emulate behaviors that aren't extensions of their native capabilities.
> Given that there isn't feature parity, Django's test suite won't be
> able to pass completely.
>
> We're in the process of migrating Django's test suite to use
> unittest2, which, in turn, means we have access to the @skipif and
> @skipunless decorators; we're going to be annotating a bunch of tests
> to make them 'feature aware' (e.g., don't run this test if the backend
> doesn't support transactions). A logical extension of this is to add
> other feature checks like "backend supports joins", and annotate the
> test suite appropriately. This would allow the noSQL backend to pass
> the suite, albeit with a lot of test skips.
>
> My (mild) concern with this approach is that a feature that this will
> make it too easy to get a suite 'passing', and we'll miss some detail
> in the process. For example, if we make it easy to skip the aggregates
> tests, and a backend actually does support aggregates, then it becomes
> easy to say "Oh, we *could* do aggregates, but we just haven't yet".
> Now, this may be entirely true, but it could also be the case that
> Django's backend API is structured in such as way that aggregates are
> impossible to implement.  Making it easy to skip tests masks the
> complications that may exist in the API.
>
> Yours,
> Russ Magee %-)
>
> --
> 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 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.
>
>

This doesn't seem like much of a regression to me.  While developing
my backend I basically ignored the existing tests because it was
impossible to learn anything from 700 test failures, of which some are
"expected and never will pass" (e.g. ones testing that we generate
only one JOIN), other are "this is something I just haven't
implemented yet, and really don't need to be told".  In fact, I view
being able to gradually increase the portion of the API you claim to
implement, as shown in your testing, as being a tremendous boon.

Alex


-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

-- 
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 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: four NoSQL backends you want? :)

[David P. Novakovic]

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 providing an interface to document stores
that isn't completely foreign to people who know how to use the django
ORM?

In which case it seems that the trust issue Russ was talking about
earlier is the main barrier here. We need more trusted people to be
using the non-rel code.

Surely that doesn't mean the project should end. Maybe there is an
interim measure that can be taken, like the django project can
recommend that people use non-rel when they want column store support
in their app with the disclaimer that it is not officially supported.
>From there it could become the defacto standard, and following that it
may be accepted?

Just throwing alternative ideas out here.

D

On Tue, Sep 28, 2010 at 9:22 AM, 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 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 column store, etc. I need to see that the API is rich
>>> enough to cover all noSQL bases.
>>>
>>
>> I've seen references to Django's test suite on this list in the past,
>> and I'm curious why the criteria can't simple be: "a clean run on our
>> test suite."
>>
>> I have a backend [1] for MonetDB (a column store DB).  They expose a SQL
>> wrapper around their non-SQL engine, which makes it pretty easy to
>> support.
>>
>> On my todo list was to see how it fares with the Django test-suite.
>> I guess the test suite must not cover all the basees, making it a
>> necessary but not sufficient criteria for inclusion?
>>
>> Correct?
>
> Well, sort of.
>
> The problem is that NoSQL stores don't necessarily have feature parity
> with relational databases. For example, the concept of a join is
> pretty fuzzy when it comes to stores like MongoDB and GAE. You *could*
> emulate join with a series of lookups, but that could get pretty
> spectacularly inefficient, so we're not going to force stores to
> emulate behaviors that aren't extensions of their native capabilities.
> Given that there isn't feature parity, Django's test suite won't be
> able to pass completely.
>
> We're in the process of migrating Django's test suite to use
> unittest2, which, in turn, means we have access to the @skipif and
> @skipunless decorators; we're going to be annotating a bunch of tests
> to make them 'feature aware' (e.g., don't run this test if the backend
> doesn't support transactions). A logical extension of this is to add
> other feature checks like "backend supports joins", and annotate the
> test suite appropriately. This would allow the noSQL backend to pass
> the suite, albeit with a lot of test skips.
>
> My (mild) concern with this approach is that a feature that this will
> make it too easy to get a suite 'passing', and we'll miss some detail
> in the process. For example, if we make it easy to skip the aggregates
> tests, and a backend actually does support aggregates, then it becomes
> easy to say "Oh, we *could* do aggregates, but we just haven't yet".
> Now, this may be entirely true, but it could also be the case that
> Django's backend API is structured in such as way that aggregates are
> impossible to implement.  Making it easy to skip tests masks the
> complications that may exist in the API.
>
> Yours,
> Russ Magee %-)
>
> --
> 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 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-develop...@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: #12012 Logging: request for comments

[Nick Phillips]

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 where is seems to
have ended up in our apps at the moment anyway; I'd agree with whoever
it was who said that it should be made possible/simple to force the
config to happen earlier in settings (and then not happen twice), as
depending on the complexity of the settings, it may be necessary to log
from it.

I'm worried by the use of "warning" for all 4xx statuses. I think it
still makes sense to use the "original" syslog level definitions[*] as a
guide, and on there I'd suggest that some 4xx statuses would merit
"Info", some "Notice", and maybe one or two "Warning". "Notice" not
being included in Python's default logging, I guess that means I'd split
them between "Info" and "Warning".

My view is that the main use of these logs to me is to help me see when
someone is doing Bad Things (or trying to) to my system. I would be
wanting anything that indicated a targeted exploration of my server to
show up as "Warning", and anything that's most likely a random script
kiddie to be "Info". That certainly puts 404 in as "Info"; I see so many
hits looking for e.g. poorly-configured phpmyadmin installations, that
404s would swamp anything that I really needed to be looking at.


[*] Which are, according to 'man syslog' on this box:

   LOG_EMERG  system is unusable
   LOG_ALERT  action must be taken immediately
   LOG_CRIT   critical conditions
   LOG_ERRerror conditions
   LOG_WARNINGwarning conditions
   LOG_NOTICE normal, but significant, condition
   LOG_INFO   informational message
   LOG_DEBUG  debug-level message


Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago

-- 
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 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: #12012 Logging: request for comments

[Russell Keith-Magee]

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? Can anyone think of a better place?
>
> In the context of running a Django app, this means it will definitely
> get called before the first request is dispatched, due to the need to
> find the URLconf. From the context of command line apps, it is less
> predictable in general, but I guess the command line app has to be
> responsible for ensuring that logging gets set up first.
>
> 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, which Hanne must presumably do already.
> The only problem is that logging could be set up twice.  For this case,
> I guess we could support some convention like 'LOGGING_CONFIG = None' to
> stop Django configuring logging altogether and add a note in the docs.
> This might also be useful for the command line app situation.

Sounds reasonable to me. I'll add handling for the None case.

>>  * The startup.py convention (and implementation). Is this necessary?
>> Does it address (or not address) any other prominent "on startup" use
>> cases? There's also a crossover here with Arthur's GSoC work; is the
>> startup code sufficiently important that we need it anyway, or can we
>> defer until the app refactor lands?
>
> I'm not sure what use cases this specifically targets. It seems that it
> depends on 'AppCache._populate' being called.  From what I can tell,
> that isn't guaranteed to be called until some database query is made, or
> it is called by an app like the admin.  Without the admin I can create
> an app that never populates AppCache but can serve responses.
>
> I don't see anything that depends on this startup proposal though, so
> I'd propose dropping that part until the other options have been
> discussed.

The use case for logging is completely customized, programatic logging
configuration. If you look at the settings.py that Vinay uploaded to
#12012, you can see an example of what he had in mind. From my
tinkering with the patch, this isn't a particularly compelling use
case; a custom logging config function should be able to handle this
much better.

The larger use case is to introduce a consistent place to do per-app
configuration, like registering signal handlers. However, the
app-cache refactor work from Arthur has a much more consistent story
on this. I think your suggested approach may be right -- drop the
startup proposal from logging (which doesn't strictly need it), and
let Arthur's work pick it up.

Yours,
Russ Magee %-)

-- 
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 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: four NoSQL backends you want? :)

[Russell Keith-Magee]

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 want to see a key-value store, and a document
>> store, and a column store, etc. I need to see that the API is rich
>> enough to cover all noSQL bases.
>>
>
> I've seen references to Django's test suite on this list in the past,
> and I'm curious why the criteria can't simple be: "a clean run on our
> test suite."
>
> I have a backend [1] for MonetDB (a column store DB).  They expose a SQL
> wrapper around their non-SQL engine, which makes it pretty easy to
> support.
>
> On my todo list was to see how it fares with the Django test-suite.
> I guess the test suite must not cover all the basees, making it a
> necessary but not sufficient criteria for inclusion?
>
> Correct?

Well, sort of.

The problem is that NoSQL stores don't necessarily have feature parity
with relational databases. For example, the concept of a join is
pretty fuzzy when it comes to stores like MongoDB and GAE. You *could*
emulate join with a series of lookups, but that could get pretty
spectacularly inefficient, so we're not going to force stores to
emulate behaviors that aren't extensions of their native capabilities.
Given that there isn't feature parity, Django's test suite won't be
able to pass completely.

We're in the process of migrating Django's test suite to use
unittest2, which, in turn, means we have access to the @skipif and
@skipunless decorators; we're going to be annotating a bunch of tests
to make them 'feature aware' (e.g., don't run this test if the backend
doesn't support transactions). A logical extension of this is to add
other feature checks like "backend supports joins", and annotate the
test suite appropriately. This would allow the noSQL backend to pass
the suite, albeit with a lot of test skips.

My (mild) concern with this approach is that a feature that this will
make it too easy to get a suite 'passing', and we'll miss some detail
in the process. For example, if we make it easy to skip the aggregates
tests, and a backend actually does support aggregates, then it becomes
easy to say "Oh, we *could* do aggregates, but we just haven't yet".
Now, this may be entirely true, but it could also be the case that
Django's backend API is structured in such as way that aggregates are
impossible to implement.  Making it easy to skip tests masks the
complications that may exist in the API.

Yours,
Russ Magee %-)

-- 
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 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: Class based models

[Klaas van Schelven]

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 the following:
from django.contrib.comments.models import CommentFlag
flag = CommentFlag()
from django.contrib.comments import get_model
mycomment = get_model().objects.get()
flag.comment = mycomment

Traceback (most recent call last):
  File "", line 1, in 
  File "...django/db/models/fields/related.py", line 318, in __set__
self.field.name, self.field.rel.to._meta.object_name))
ValueError: Cannot assign "":
"CommentFlag.comment" must be a "Comment" instance.

You see the problem? Any help thinking about the solution is much
appreciated.

Klaas

On Sep 27, 7:57 pm, "subs...@gmail.com"  wrote:
> 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 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, 8:28 am, Klaas van Schelven 
> > > wrote:
>
> > > > Hi all,
>
> > > > I'm looking for a bit of input for making Django's apps a bit more
> > > > extendable, either by modifying Django or (preferably) by coming up
> > > > with a common language on top op Django. The main painpoint are
> > > > extendable models. The idea of 'extendable' is that models from
> > > > reusable apps can be extended in any concrete project. The reusable
> > > > apps should refer to their own models in such a way that they will get
> > > > the concrete implementation (extension).
> > > > Class based models if you will.
>
> > > > Context can be found 
> > > > here:http://groups.google.com/group/django-users/browse_thread/thread/2287...
>
> > > > Currently, apps usually refer to their own models by simply importing
> > > > them from models.py and referring to them. This obviously will not
> > > > work, so any solution will need some kind of registry, or instance of
> > > > "app". If "app" is an instance of a class referring to it can be done
> > > > in an extendible way (simply by using Python's inheritance mechanism).
>
> > > > I've put an example of this approach 
> > > > here:http://bitbucket.org/vanschelven/extendible_app_experiment/src/0862ce...
>
> > > > Which incorporates the above idea of an app class & instance in blog/
> > > > __init__.py.
>
> > > > abstract_blog/abstract_models.py and blog/models.py
>
> > > > The key sections are:
> > > > (in abstract_models)
>
> > > >     def get_AbstractPage(self):
> > > >         class AbstractPage(models.Model):
> > > >             body = models.TextField()
> > > >             category = models.ForeignKey(self.app.models.Category)
>
> > > >             class Meta:
> > > >                 abstract = True
> > > >                 #app_label = 'abstract_blog'
> > > >         return AbstractPage
> > > >     AbstractPage = property(get_AbstractPage)
>
> > > > (in models)
> > > >     def get_Category(self):
> > > >         class Category(self.AbstractCategory):
> > > >             some_added_field = models.IntegerField()
> > > >         return Category
> > > >     Category = property(get_Category)
>
> > > > As you can see, it is possible to refer to "the apps real
> > > > implementation of Category" (self.app.models.Category, or just
> > > > self.Category) from the abstract model. Less neat: the cruft that's
> > > > needed to pass self into AbstractPage for reference (3 lines per
> > > > class: def, return & property).
>
> > > > In a more recent version I've managed to factor those lines away at
> > > > the cost of a lot of 
> > > > magic.http://bitbucket.org/vanschelven/extendible_app_experiment/src/2b8eb6...
>
> > > > class AbstractModels(object):
> > > >     #...
> > > >     class AbstractPage(shmodels.Model):
> > > >         body = shmodels.TextField()
> > > >         category =
> > > > shmodels.ForeignKey(Zelf("app.models.Category"))
>
> > > > Neet uh? Self referral without an actual introduction of "self".
>
> > > > I may look for the general case of Zelf & Zelf2 and shmodels and
> > > > whatever... but I'd like to know that this is a path worth following.
> > > > In other words: am I missing really obvious, more simple solutions
> > > > here?
>
> > > > ciao,
> > > > Klaas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to 

Re: #12012 Logging: request for comments

[Hanne Moa]

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, which Hanne must presumably do already.
> The only problem is that logging could be set up twice.  For this case,
> I guess we could support some convention like 'LOGGING_CONFIG = None' to
> stop Django configuring logging altogether and add a note in the docs.
> This might also be useful for the command line app situation.

This might be useful for switching over to the official logging
system, easily turning it on and off.

I've been using the logging system since before it was added to
python. There used to be problems with it hiding some exceptions but
that was in some hideously complex threads, multicast and
ldap-disaster, so it might have been something else hiding those
exceptions. I haven't seen any such in the duct tape-and-chewing gum
setup I use in my django projects right now.

If anyone is looking for inspiration: most modules longer than twenty
lines starts with

import logging
_LOG = logging.getLogger(__name__)
_LOG.info(__name__)

.. so I know that they imported correctly on the production-server.

I've also on occasion used decorators to log state on entry and exit
of views and functions, in addition to liberal sprinkling through code
that really ought to be refactored. I even add it to django itself in
order to understand what's going on.


HM

-- 
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 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: dates postgres django trunk

[shmengie]

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" group.
To post to this group, send email to django-develop...@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.

feature request: insensitive 'in'?

[Daniel]

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 
"Django developers" group.
To post to this group, send email to django-develop...@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: dates postgres django trunk

[Will Hardy]

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 leaving the % signs
out. What might be confusing for some is that the documentation for
DATE_INPUT_FORMATS directly below it, shows an example with lots of %
sign formats. It also seems that the reference to "allowed date format
strings" isn't a working link, is that a bug in the documentation?

Cheers,

Will

[1] http://docs.djangoproject.com/en/dev/ref/settings/#date-format

-- 
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 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: four NoSQL backends you want? :)

[Mark Bucciarelli]

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 column store, etc. I need to see that the API is rich
> enough to cover all noSQL bases.
>

I've seen references to Django's test suite on this list in the past,
and I'm curious why the criteria can't simple be: "a clean run on our
test suite."

I have a backend [1] for MonetDB (a column store DB).  They expose a SQL
wrapper around their non-SQL engine, which makes it pretty easy to
support.

On my todo list was to see how it fares with the Django test-suite.
I guess the test suite must not cover all the basees, making it a
necessary but not sufficient criteria for inclusion?

Correct?

Thanks,

m

[1] http://github.com/mbucc/monetdb-python

-- 
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 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.

dates postgres django trunk

[shmengie]

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
DATE_FORMAT = "%m/%d/%Y"

appears to have no effect.

-- 
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 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: proposal for lazy foreignkeys

[Patryk Zawadzki]

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 class):
>>
>> http://gist.github.com/584106
> This looks rather good to me.  It may have been ignored before because
> it has no comments and some things are not immediately obvious.  For
> example, you are basically proposing that the concrete models are passed
> into view functions via URLconf, and from there are passed into any
> functions which need them, and so they would never actually need to be
> imported by the app that defines the abstract model.
>
> I for one would be much happier to not add any more machinery via Meta
> options. With some cleanup, and some documentation of this pattern, and
> possibly a better name, I think the AbstractMixin class you propose
> could be a good candidate for inclusion in core.
>
> Some notes:
> 1) it seems like line 15 in abstract.py should say 'abstract':'False',
> not 'True' - did I miss something?

It is there because I inherit from the .construct() result rather than
taking it directly as a solid class. This helps with debugging as all
the tracebacks show proper module for the model.

> 2) there would need to be some way of merging the concrete class's own
> Meta options with the abstract class's Meta options

True.

> 3) why do we need the _classcache?  Is the key used specific enough -
> what if two different apps both create 'MyCategory' based on
> 'CategoryFactory', using them in different situations?

I did it so there was no way to create two different mechanics for the
same model accidentally.

-- 
Patryk Zawadzki

-- 
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 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: proposal for lazy foreignkeys

[Luke Plant]

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 = CategoryFactory.construct()

Thanks,

Luke

-- 
"Christ Jesus came in to the world to save sinners" (1 Timothy 1:15)

Luke Plant || http://lukeplant.me.uk/

-- 
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 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: proposal for lazy foreignkeys

[Luke Plant]

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 rather good to me.  It may have been ignored before because
it has no comments and some things are not immediately obvious.  For
example, you are basically proposing that the concrete models are passed
into view functions via URLconf, and from there are passed into any
functions which need them, and so they would never actually need to be
imported by the app that defines the abstract model.

I for one would be much happier to not add any more machinery via Meta
options. With some cleanup, and some documentation of this pattern, and
possibly a better name, I think the AbstractMixin class you propose
could be a good candidate for inclusion in core.

Some notes:
1) it seems like line 15 in abstract.py should say 'abstract':'False',
not 'True' - did I miss something?

2) there would need to be some way of merging the concrete class's own
Meta options with the abstract class's Meta options

3) why do we need the _classcache?  Is the key used specific enough -
what if two different apps both create 'MyCategory' based on
'CategoryFactory', using them in different situations?

Thanks,

Luke

-- 
"Christ Jesus came in to the world to save sinners" (1 Timothy 1:15)

Luke Plant || http://lukeplant.me.uk/

-- 
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 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: #12012 Logging: request for comments

[Luke Plant]

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 running a Django app, this means it will definitely
get called before the first request is dispatched, due to the need to
find the URLconf. From the context of command line apps, it is less
predictable in general, but I guess the command line app has to be
responsible for ensuring that logging gets set up first.

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, which Hanne must presumably do already.
The only problem is that logging could be set up twice.  For this case,
I guess we could support some convention like 'LOGGING_CONFIG = None' to
stop Django configuring logging altogether and add a note in the docs.
This might also be useful for the command line app situation.

>  * The default logging configuration. Have I got the
> propagate/override options right for sensible defaults (both in global
> and new-project settings)?

I don't really have much experience with the logging module, but they
seemed sensible to me.

> * The logging calls that have been introduced. Is this too much or
> too little? I'd rather err on the side of caution here (we can always
> add extra logging later), but I'd like suggestions on anything else
> people think should be logged. Also, are they logged at the right
> level (e.g., is a 404 a warning?).

These all look good to me, and cover the obvious cases.  Warnings for
4XX codes seems good, since they could be a sign of something "going
wrong" - dead links or some kind of attack - while not necessarily being
an actual problem in the code, and it is useful to filter that category.

>  * The startup.py convention (and implementation). Is this necessary?
> Does it address (or not address) any other prominent "on startup" use
> cases? There's also a crossover here with Arthur's GSoC work; is the
> startup code sufficiently important that we need it anyway, or can we
> defer until the app refactor lands?

I'm not sure what use cases this specifically targets. It seems that it
depends on 'AppCache._populate' being called.  From what I can tell,
that isn't guaranteed to be called until some database query is made, or
it is called by an app like the admin.  Without the admin I can create
an app that never populates AppCache but can serve responses.

I don't see anything that depends on this startup proposal though, so
I'd propose dropping that part until the other options have been
discussed.

Regards,

Luke

-- 
"Christ Jesus came in to the world to save sinners" (1 Timothy 1:15)

Luke Plant || http://lukeplant.me.uk/

-- 
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 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: Application, tempaltetags and namespace

[Iván Raskovsky]

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 myself.
> There are two tickets related to this problem:
>
> #2539: Namespacing for template tags
> #12772: Loading by fully qualified path name
>
> Template tag namespacing has been accepted as an idea; it's just
> waiting on a trunk-ready patch.
>
> Loading by fully qualified path is currently marked DDN; On principle,
> the idea seems sound to me, but it requires more thought in terms of
> how the new loading scheme will interact with existing code.

I've proposed a solution[1] some time ago, where I also gathered all
the discussions on the topic I could find. Sadly I got no feedback.
Iván

[1] 
http://groups.google.com/group/django-developers/browse_thread/thread/da9ed3a3116c546a/88d0d780a5e9d09f?lnk=gst=namespaces#88d0d780a5e9d09f

-- 
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 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: Application, tempaltetags and namespace

[Eric Holscher]

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 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 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: 'User' object has no attribute 'backend' - issue with using auth.login()

[Tom Evans]

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 which isn't a user but is able to login.
>
> Besides.. is_active does not mean you're not allowed to log in.. I'm
> currently on a website where a user can register and do things on the
> website right away and they won't be active till they have verified
> their e-mail address. So the in active user can login and start using
> the basic features right away.
>

As far as django.contrib.auth is concerned it does. If your login
forms extend from django.contrib.auth.forms.AuthenticationForm, you
wouldn't be able to log in using an inactive account.

The help text for is_active also clearly indicates the intended usage
of this flag:
"Designates whether this user should be treated as active. Unselect
this instead of deleting accounts."

Of course, if you work around all that, and don't use most of the
contrib.auth framework, then you can use it to mean anything you like.


Cheers

Tom

-- 
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 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: Class based models

[Klaas van Schelven]

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, 8:28 am, Klaas van Schelven 
> wrote:
>
>
>
> > Hi all,
>
> > I'm looking for a bit of input for making Django's apps a bit more
> > extendable, either by modifying Django or (preferably) by coming up
> > with a common language on top op Django. The main painpoint are
> > extendable models. The idea of 'extendable' is that models from
> > reusable apps can be extended in any concrete project. The reusable
> > apps should refer to their own models in such a way that they will get
> > the concrete implementation (extension).
> > Class based models if you will.
>
> > Context can be found 
> > here:http://groups.google.com/group/django-users/browse_thread/thread/2287...
>
> > Currently, apps usually refer to their own models by simply importing
> > them from models.py and referring to them. This obviously will not
> > work, so any solution will need some kind of registry, or instance of
> > "app". If "app" is an instance of a class referring to it can be done
> > in an extendible way (simply by using Python's inheritance mechanism).
>
> > I've put an example of this approach 
> > here:http://bitbucket.org/vanschelven/extendible_app_experiment/src/0862ce...
>
> > Which incorporates the above idea of an app class & instance in blog/
> > __init__.py.
>
> > abstract_blog/abstract_models.py and blog/models.py
>
> > The key sections are:
> > (in abstract_models)
>
> >     def get_AbstractPage(self):
> >         class AbstractPage(models.Model):
> >             body = models.TextField()
> >             category = models.ForeignKey(self.app.models.Category)
>
> >             class Meta:
> >                 abstract = True
> >                 #app_label = 'abstract_blog'
> >         return AbstractPage
> >     AbstractPage = property(get_AbstractPage)
>
> > (in models)
> >     def get_Category(self):
> >         class Category(self.AbstractCategory):
> >             some_added_field = models.IntegerField()
> >         return Category
> >     Category = property(get_Category)
>
> > As you can see, it is possible to refer to "the apps real
> > implementation of Category" (self.app.models.Category, or just
> > self.Category) from the abstract model. Less neat: the cruft that's
> > needed to pass self into AbstractPage for reference (3 lines per
> > class: def, return & property).
>
> > In a more recent version I've managed to factor those lines away at
> > the cost of a lot of 
> > magic.http://bitbucket.org/vanschelven/extendible_app_experiment/src/2b8eb6...
>
> > class AbstractModels(object):
> >     #...
> >     class AbstractPage(shmodels.Model):
> >         body = shmodels.TextField()
> >         category =
> > shmodels.ForeignKey(Zelf("app.models.Category"))
>
> > Neet uh? Self referral without an actual introduction of "self".
>
> > I may look for the general case of Zelf & Zelf2 and shmodels and
> > whatever... but I'd like to know that this is a path worth following.
> > In other words: am I missing really obvious, more simple solutions
> > here?
>
> > ciao,
> > Klaas

-- 
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 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: proposal for lazy foreignkeys

[Patryk Zawadzki]

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) completely different ways of solving the same problem.
> At the very least, I'd like to have some certainty that the solution
> for single concrete class problem will be conceptually similar to the
> multiple concrete class problem.

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

-- 
Patryk Zawadzki

-- 
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 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: 'User' object has no attribute 'backend' - issue with using auth.login()

[Will Hardy]

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, which is then used when you use
django.contrib.auth to login.


Django's auth design is fine for a huge number of django developers, I
get the feeling that people here are skeptical that you have found an
architectural/design bug. If you're absolutely certain this isn't
possible for you, then keep pursuing this. But be wary that doing so
might distract a lot of people from other tasks, I hope it's worth it!

I like the idea of improving the exception raised when .backend is
missing. I think working on a patch to improve the exception raised
would be a perfectly sensible improvement to django.

Cheers,

Will

-- 
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 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: Proposal: Meta.required_together

[Yo-Yo Ma]

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 provide a weight
and height, if you intend to use either.'),)

unique_together = (('account', 'sku', 'This sku is already in use by
your company.'),)

On Sep 27, 1:22 am, "David P. Novakovic" 
wrote:
> 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 of a much larger problem though.
> That problem is multifield validation. I think we'd have to address
> that issue first before working on this specific case that is probably
> the simplest.
>
> Maybe this has been considered before, but was dropped because the
> idea is too hard to encapsulate in a simple Meta style option?
>
> David
>
> On Mon, Sep 27, 2010 at 5:18 PM, Florian Apolloner
>
>  wrote:
> > 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 from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://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-develop...@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: Proposal: Meta.required_together

[Florian Apolloner]

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 on a regular base)

> This is about conditionally requiring a second field if one is filled
> out. Normally it would be done at the JS level.
JS level + Server level

> I think it's a good idea, assuming I haven't missed something that
> already does this.
Yes, form.clean and the model validation can do it.

> I can't help thinking this is part of a much larger problem though.
> That problem is multifield validation. I think we'd have to address
> that issue first before working on this specific case that is probably
> the simplest.
Why is multifield validation a problem? I works (tm).

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 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: Proposal: Meta.required_together

[David P. Novakovic]

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 of a much larger problem though.
That problem is multifield validation. I think we'd have to address
that issue first before working on this specific case that is probably
the simplest.

Maybe this has been considered before, but was dropped because the
idea is too hard to encapsulate in a simple Meta style option?

David

On Mon, Sep 27, 2010 at 5:18 PM, Florian Apolloner
 wrote:
> 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 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-develop...@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: Proposal: Meta.required_together

[Yo-Yo Ma]

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 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 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: #12012 Logging: request for comments

[Vinay Sajip]

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 upon the use of global
> variables, they would be soundly ridiculed; but for some reason,
> calling that same global variable a "threadlocal" makes it socially
> acceptable.
>

You're right in many ways, but these things are there because they're
useful. You can't even get away from globals - every module is a
global, and there's even a global list of them in sys.modules. Even
the global settings in Django, which are the cause of a lot of pain,
have been very useful in their way.

It's definitely true that in the hands of the Wrong People, abuse of
thread-locals could lead to maintainability nightmares. But that's not
to say that there's no place for them anywhere; it's just that you
have to provide very clear do's and dont's. This problem is not
specific to thread-locals; an analogous case occurs in class-based
views. There's no question (IMO) that class-based views can be a real
boon, but they also need a warning label about not storing state in
the class instance when processing requests.

Interestingly, in the use case I mentioned, the use of thread-locals
leads to a decrease of coupling in the sense that some third-party
library knows nothing about the thread it's being called from or the
request that it's helping to process, yet its logging messages can
contain that context and thus be more useful. The alternative would
perhaps be to e.g. pass a request from the view layer into the lower
layers of code, which (a) would lead to increased coupling for no real
benefit (methods which include the request in their signatures just so
it can be reflected in log messages, for example), and (b) might not
even be possible if you are using third-party code to do a decent
chunk of your work for you (and that's code you can't easily control,
and have no say in the design of).

> It is entirely possible to build a robust, testable web system without
> the use of threadlocals. You just need to be thorough in your design
> work.
>

Modulo the use of third-party code, the design of which you generally
don't have much influence over.

By and large, I think we're in agreement: I just think that thread-
locals have their place, but must be used with care and under the
guidance of experienced practitioners.

Regards,

Vinay Sajip

-- 
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 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: Proposal: Meta.required_together

[Florian Apolloner]

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 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: #12012 Logging: request for comments

[mattimust...@gmail.com]

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 concerned about logging performance for your particular
application then you might want to consider NonblockingLogHandler [1].

[1] http://www.somethinkodd.com/oddthinking/nonblocking-log-handler/


Regards

--
Matthew Flanagan
http://wadofstuff.blogspot.com

> Regards,
>
> --
> Antoni Aloy López
> Blog:http://trespams.com
> Site:http://apsl.net

-- 
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 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: Application, tempaltetags and namespace

[Russell Keith-Magee]

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
>
> hello.world
>
> with the following structure:
>
> hello.world/
>  setup.py
>  hello/
>    world/
>     ...
>
> If you have an application called common and a templatags named
> featured_product, there's no way to it seems to force django to refer
> only to the complete name like that:
>
> hello.world.common
>
> and
>
> hello.world.common.featured_products
>
> it caused sometime some problems related to conflicting names and more
> than that, it means we are not completely explicit but magic.
>
> What do you think ?

There are two tickets related to this problem:

#2539: Namespacing for template tags
#12772: Loading by fully qualified path name

Template tag namespacing has been accepted as an idea; it's just
waiting on a trunk-ready patch.

Loading by fully qualified path is currently marked DDN; On principle,
the idea seems sound to me, but it requires more thought in terms of
how the new loading scheme will interact with existing code.

Yours,
Russ Magee %-)

-- 
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 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.