It's decided then... No schema creation.
Thanks for good input and fast response...
Peter
On 18 Aug, 02:08, Russell Keith-Magee wrote:
> On Mon, Aug 17, 2009 at 11:12 PM, Ian Kelly wrote:
>
> > On Mon, Aug 17, 2009 at 8:19 AM, kmpm wrote:
>
> >> I'm working on issuehttp://code.djangoproject.co
> This is actually pretty much exactly what I had before, it was horribly
> slow! And somehow not nice since you always have to wrap the users
> around and can't just use request.user...
When you say that it was "horribly slow," does that mean you weren't
using caching to skip the DB, or was it s
On Mon, Aug 17, 2009 at 11:12 PM, Ian Kelly wrote:
>
> On Mon, Aug 17, 2009 at 8:19 AM, kmpm wrote:
>>
>> I'm working on issue http://code.djangoproject.com/ticket/6148 and
>> have some questions.
>>
>> If a db_schema is defined, should it be created automatically or
>> should the user be required
On Aug 18, 12:35 am, Dave Jeffery wrote:
> (Sticking my nose in where it isn't wanted...) The toolbar looks really
> great but it feels a bit over-designed and too heavy for a functional
> interface which will sit atop of existing websites. I'm especially referring
> to the typography, the upperc
On Mon, Aug 17, 2009 at 2:28 PM, Jacob Kaplan-Moss wrote:
>
> The reasoning was that we wanted the error pages to be somewhat
> framework-agnostic;
> we didn't want to impose our branding onto parts of *your* site. I'd
> say a similar ethos should be expressed in the debug toolbar branding.
> If y
On Aug 17, 4:28 pm, Jacob Kaplan-Moss wrote:
> I'd say a similar ethos should be expressed in the debug toolbar branding.
> If you wanted to be extra special, some UI similarity between the
> error pages and the debug toolbar would probably be a good idea.
Fair 'nuff. I'll squash the last remain
Hi folks,
finally I had no time to start coding on multilingual models, as part of
my GSoC project. I did some more analysis on the problem, and possible
solutions; let me share them with you.
Basically, I arrived to the conclusion that there are two different
approaches, both valid, and ever
James Bennett wrote:
> On Mon, Aug 17, 2009 at 10:57 AM, Jonas Obrist wrote:
>
>> Thanks for your opinion on this, didn't know django had this feature
>> once. But I just can't get it out of my head that there's gotta be a
>> better solution than this profile-extending... It just seems ridiculo
If i use the standard `objects` (models.Manager) as the default
manager, the all the inlines display. If i use another manager as the
default (first listed in the model definition) that excludes some
instances, the inlines are missing. You can see this if you change
the ordering of the managers
On Mon, Aug 17, 2009 at 11:35 AM, James Bennett wrote:
> def __getattr(self, name):
> if hasattr(self.user, name):
> return getattr(self.user, name)
> else:
> return getattr(self.profile, name)
And for some reason gmail ate the trailing double underscores --
On Mon, Aug 17, 2009 at 10:57 AM, Jonas Obrist wrote:
> Thanks for your opinion on this, didn't know django had this feature
> once. But I just can't get it out of my head that there's gotta be a
> better solution than this profile-extending... It just seems ridiculous
> to me that half of the use
On Mon, Aug 17, 2009 at 11:57 AM, Jonas Obrist wrote:
>
> Hey Jacob
>
> Thanks for your opinion on this, didn't know django had this feature
> once. But I just can't get it out of my head that there's gotta be a
> better solution than this profile-extending... It just seems ridiculous
> to me that
Hey Jacob
Thanks for your opinion on this, didn't know django had this feature
once. But I just can't get it out of my head that there's gotta be a
better solution than this profile-extending... It just seems ridiculous
to me that half of the user properties is in one table and the other
half
On Mon, Aug 17, 2009 at 8:19 AM, kmpm wrote:
>
> I'm working on issue http://code.djangoproject.com/ticket/6148 and
> have some questions.
>
> If a db_schema is defined, should it be created automatically or
> should the user be required to set this up in the same fashion as he
> is required to se
On Mon, Aug 17, 2009 at 1:44 PM, Jacob Kaplan-Moss wrote:
>
> On Mon, Aug 17, 2009 at 9:10 AM, Joshua Russo
> wrote:
> > I will try hooking into both post_save and post_delete signals though I
> was
> > looking for a more unified approach, to avoid repetition.
>
> You may already know this, but yo
Jacob Kaplan-Moss wrote:
> Hi folks --
>
> Y'know, there's quite a bit of bike-shedding going on in this
> discussion, and not a whole lot of code writing. Remember that our
> general policy is that whoever builds the shed gets to paint it; y'all
> might want to spend some of this energy actually
On Mon, Aug 17, 2009 at 9:10 AM, Joshua Russo wrote:
> I will try hooking into both post_save and post_delete signals though I was
> looking for a more unified approach, to avoid repetition.
You may already know this, but you can hook the same method up to
multiple signals::
def handle_save_
Hi Jonas --
On Mon, Aug 17, 2009 at 7:43 AM, Jonas Obrist wrote:
> Basically it lets you define a class in settings which extends the User
> table before it's created, using subclassing.
This is a non-starter. It's not going to happen.
Back in the day, Django actually had this "feature." There
Hi folks --
Y'know, there's quite a bit of bike-shedding going on in this
discussion, and not a whole lot of code writing. Remember that our
general policy is that whoever builds the shed gets to paint it; y'all
might want to spend some of this energy actually working on a patch.
Jacob
--~--~--
Oh that's right, reason I put this in ModelAdmin is because I'm clearing
session variables and so I need the request object. (So signals won't work.
I don't believe.) When dealing with the request object there isn't a real
clean way to centralize management like this. By adding the model_modified
h
Martin Maney wrote:
> On Sat, Aug 15, 2009 at 10:45:44AM -0700, hcarvalhoalves wrote:
>> ForeignKey(..., propagate_on_delete=True)
>> CASCADE
>>
>> ForeignKey(..., propagate_on_delete=False, null=False)
>> RESTRICT
>>
>> ForeignKey(..., propagate_on_delete=False, null=True)
>> SET NULL
>>
>> Forei
The problem with simply extending the save method is that it doesn't cover
deletes.
I will try hooking into both post_save and post_delete signals though I was
looking for a more unified approach, to avoid repetition.
On Mon, Aug 17, 2009 at 12:11 PM, Marc Remolt wrote:
>
> May I ask why you don
I'm working on issue http://code.djangoproject.com/ticket/6148 and
have some questions.
If a db_schema is defined, should it be created automatically or
should the user be required to set this up in the same fashion as he
is required to set up the database.
For postgres it might not be any troub
Hey Idan --
On Mon, Aug 17, 2009 at 7:21 AM, Idan Gazit wrote:
> I've been working on prettyfication of the DDT. Github:
> http://github.com/idangazit/django-debug-toolbar/tree/idan-ui-rf. It's
> a reasonably complete reskinning of the existing DDT. There are still
> a couple of outstanding issue
May I ask why you don't simply extend the models save method or use a
post save signal
(http://docs.djangoproject.com/en/dev/ref/signals/#django.db.models.signals.post_save)?
Do you really want the cleanups only if the object is saved via the
admin or whenever it is saved - for example in your
Hi django-developers
I wasn't quite happy with how django.contrib.auth handles extending the
User table. So I changed the auth system and in my opinion it's a better
solution.
The code can be found here: http://dpaste.com/81651/
Basically it lets you define a class in settings which extends t
Oh, forgot to include the screencast:
http://s3.pixane.com.s3.amazonaws.com/ddt-ui-refresh.mov
-I
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djang
I've been working on prettyfication of the DDT. Github:
http://github.com/idangazit/django-debug-toolbar/tree/idan-ui-rf. It's
a reasonably complete reskinning of the existing DDT. There are still
a couple of outstanding issues but the redesign is largely finished.
I didn't use the admin color pa
28 matches
Mail list logo
