Trying not to repeat myself too much while arguing for my fast-fading
favorite... :)
> Yeah, you really better, since I don't like it one bit :)
>
> Currently the settings file for lawrence.com has... (/me checks)...
> 48 entries. You mean I've got to duplicate my database settings 48
> times!?
Another use case to mull around:
I'm currently using django for basically everything *but* it's ORM, in
large part due to not supporting multiple databases. We have one
software package with many nearly-identical databases (for different
customers). The models would be the same, but I'd want to
> Under your proposal, I need to write DATABASE_ENGINE and DATABASE_NAME
> once for each application, because there is no way to group the
> information is even one of my applications needs a different database.
> That seems like a lot more configuration (longer config files are harder
> to
On Mon, 2006-07-10 at 22:24 -0500, Jacob Kaplan-Moss wrote:
> On Jul 10, 2006, at 10:09 PM, jason pellerin wrote:
[...]
> >> Finally: will there be syntax to use a specific connection for some
> >> operations even if that model's set up to use a different backend?
> >> I'd hope so, but I'm not
On Mon, 2006-07-10 at 20:05 -0700, Gary Wilson wrote:
> Proposing an is_loggedin method for User and AnonymousUser models.
>
> Templates treat non-existing variables as False; therefore; a
> request.user somehow failing to get assigned would result in the
> template treating the user as they are
On Jul 10, 2006, at 10:09 PM, jason pellerin wrote:
> Thanks, Jacob. And yes please, more eyes are badly needed. Aside from
> dropping tables, the branch is fully functional -- please try it out!
I've svn swich'd and I'm fooling with it now...
> This is interesting. How would it work -- look up
On Mon, 2006-07-10 at 22:09 -0500, jason pellerin wrote:
> Hi all,
>
> Thanks, Jacob. And yes please, more eyes are badly needed. Aside from
> dropping tables, the branch is fully functional -- please try it out!
>
> > I'd like to see this done the other way around, which the DATABASES
> >
On Jul 10, 2006, at 9:55 PM, Malcolm Tredinnick wrote:
> I agree with most of your points (the settings one is actually kind of
> obvious that it may be backwards now that you mention it).
> Inter-database relations would be nice to have at some point, but it
> could be a post-first-release kind
Hi all,
Thanks, Jacob. And yes please, more eyes are badly needed. Aside from
dropping tables, the branch is fully functional -- please try it out!
> I'd like to see this done the other way around, which the DATABASES
> settings defining which *models* are used. I'm picturing something
> like
Proposing an is_loggedin method for User and AnonymousUser models.
Templates treat non-existing variables as False; therefore; a
request.user somehow failing to get assigned would result in the
template treating the user as they are authenticated (is_anonymous
evaluates False). An is_loggedin
I agree with most of your points (the settings one is actually kind of
obvious that it may be backwards now that you mention it).
Inter-database relations would be nice to have at some point, but it
could be a post-first-release kind of feature.
On Mon, 2006-07-10 at 21:38 -0500, Jacob
On 11/07/2006, at 12:22 PM, Malcolm Tredinnick wrote:
>>
>> is this totally out of line?
>> or should I just be using the 'regular' cache here.
>
> Tricky implementation ("tricky" != "bad"), but it looks like it should
> work more or less. Don't you need to override every public method of
>
that would work too
;-)
(always looking for the complex way of doing things)
On 11/07/2006, at 12:41 PM, Jacob Kaplan-Moss wrote:
>
> On Jul 10, 2006, at 8:59 PM, Ian Holsman wrote:
>> this is what I was thinking of
>
> I'm all for the idea if it uses django.core.cache (as Adrian
>
Hey Ian,
On Tue, 2006-07-11 at 11:59 +1000, Ian Holsman wrote:
> this is what I was thinking of
> from django.db import models
> from django.db.models.query import QuerySet
>
> class SmallQuerySet(QuerySet):
> cache={}
> def get(self, *args, **kwargs):
> cachekey = "%s:%s:%s"
On 7/10/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> class SmallQuerySet(QuerySet):
> cache={}
> def get(self, *args, **kwargs):
> cachekey = "%s:%s:%s" % (self.model, str(args), str(kwargs ) )
> if self.cache.has_key( cachekey ) :
> return
this is what I was thinking of
from django.db import models
from django.db.models.query import QuerySet
class SmallQuerySet(QuerySet):
cache={}
def get(self, *args, **kwargs):
cachekey = "%s:%s:%s" % (self.model, str(args), str(kwargs ) )
if self.cache.has_key(
Is there any discussion on the fate of manipulators? I've done a lot
on my own to make it more managable (including making a very cool
'remote manipulator that executes via ajax'), so I'd like to see where
this is all going, a plan or what not.
Thanks.
On 7/10/06, Adrian Holovaty <[EMAIL
On 7/10/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> I've thought that models will gain validation, but manipulators
> will stay and provide an additional level of validation for stuff
> that e.g. needs custom manipulators. Did I miss something? Can
> someone shed some light onto this?
Hey
On 7/10/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 7/7/06, Deryck Hodge <[EMAIL PROTECTED]> wrote:
> > Did this ever get resolved? The thread looks like docs generation was
> > fixed but I see nothing about the django-updates list. I still
> > haven't seen anything to that list since
On 7/7/06, Deryck Hodge <[EMAIL PROTECTED]> wrote:
> Did this ever get resolved? The thread looks like docs generation was
> fixed but I see nothing about the django-updates list. I still
> haven't seen anything to that list since early June. Is it no longer
> used?
I have no idea what
Oh, cool! thanks
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
On Mon, 2006-07-10 at 15:01 +0200, Michael Radziej wrote:
> Malcolm Tredinnick wrote:
> > The __import__() call does not reimport the module if it already exists
> > in sys.modules. It works just like the "import" statement in Python (and
> > reload() works like imp.load_module()). So, aside from
Malcolm Tredinnick wrote:
> The __import__() call does not reimport the module if it already exists
> in sys.modules. It works just like the "import" statement in Python (and
> reload() works like imp.load_module()). So, aside from a single
> dictionary lookup, there is no overhead to calling it
adurdin wrote:
> #2207 was closed as "wontfix", because Adrian said:
>
>> Because the automatic manipulators (in their current form) are going away
>> before 1.0, there's no point in adding this to Django.
> ...
Thanks, that explains quite a bit. #1563 is specifically about
custom
Hi,
I'm confused by a comment of Adrian in ticket 1563:
> Because manipulators are going away, I don't think we should do
this.
I've thought that models will gain validation, but manipulators
will stay and provide an additional level of validation for stuff
that e.g. needs custom manipulators.
First, a little context. My app uses cookie-based authorization as well
as HTTP authorization (for download managers mostly). It worked as a
middleware that sits after Django's auth middleware and tries to
authorize a user by HTTP credentials if it's not authorized with
cookies. It goes
26 matches
Mail list logo
