Adrian Holovaty wrote:
> Would you be comfortable doing this on the magic-removal branch? I ask
> because that branch has *several* backwards-incompatible changes (see
> http://code.djangoproject.com/wiki/RemovingTheMagic), and I wouldn't
> yet call it stable. On the other hand, it's what will bec
I said:
> Doesn't the delete function also check permissions on all the referenced rows?
I tested this and found a bug (#1250), but I confirmed that you cannot
delete items through the admin interface if you don't have delete
permissions to ALL related objects.
-rob
On 1/19/06, Jason Huggins <[EMAIL PROTECTED]> wrote:
> I have my own personal svn checkout folder on my laptop where I'm
> keeping the patch up-to-date with Django's trunk, but I'm beginning to
> think it would be better if this lived in a branch on the Django's
> project repository.
Definitely a
I spent some quality time bringing my Oracle patch for Djagno
up-to-date with the most recent svn version stamp as of Monday evening.
I still have some issues with it, though, specifically logging into the
admin app. I think it is a problem somewhere in the session middleware
and how it's dealing
> It's not just the referential integrety - even though that's
complicated enough, with ISPs not allways installing newest versions of
databases - but the .delete() overloading, too. If your class overloads
.delete() to do specific stuff, that code will not be called when you
do bulk deletes.
Doe
Yes, I'm bringing this up yet again. I have a new idea though,.
Hopefully this is closer to making everyone happy.
It's a common usage pattern to set some values in the request before
they are passed into the manipulator. You should be able to save
things like the current user's id, the client's
>This is exactly what Django used to do, actually, back when it was
>Postgres-only. Such are the compromises of having to support other
>DBs. :-/
Maybe it would be a good idea to add stuff to the Django backend
modules so that real databases can make use of referential integrity
and cascaded dele
>I've been looking at the code for normal object deletion in an attempt
>to get the same behaviour for bulk delete. It seems like there is a
>lot of logic dedicated to maintaining referential integrity that the
>database could be doing (and would probably do more efficiently).
It's not just the r
What is so strange about "myapp.admin as admin" ?Users of Django are usually familiar with such syntax - SQL uses that, Python import uses that. From the user readibility I prefer it.With:
INSTALLED_APPS = ( 'foo.bar.baz', ('foo.baz.baz', 'baz2'),)you will have to deal with several brackets a
Dear ALL
I still have a problem with the picture feild here what i have done
1- I write this in my page.py: full_image = meta.ImageField(upload_to
="/media/images/", null = True, blank = True )
2-i opened the admin page and load the pictuer i need
i found that it creat a folder and it's path is /
On 1/19/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
On 1/19/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:>> On 1/19/06, Russell Keith-Magee <[EMAIL PROTECTED]
> wrote:> > It seems like most of the internal reference walking logic in the> > object.delete() call would be eliminated if the for
hugo wrote:
>>+1. Gets around the reserved word problem entirely, and removes a
>>little bit more magic from model definitions.
>
>
> Problem with that discussion was, IIRC, that neither Adrian nor Jacob
> where very fond of allways having to explicitely provide the manager.
> So the result of t
On 1/19/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/19/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > It seems like most of the internal reference walking logic in the
> > object.delete() call would be eliminated if the foreign key fields
> > were declared ON DELETE CASCADE or
From their 3.3.1 alpha notes:
Database connections can now be moved between threads as long as the
connection holds no locks at the time it is moved. Thus the common
paradigm of maintaining a pool of database connections and handing
them off to transient worker threads is now supported. Please hel
On 1/19/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> I've been looking at the code for normal object deletion in an attempt
> to get the same behaviour for bulk delete. It seems like there is a
> lot of logic dedicated to maintaining referential integrity that the
> database could be doing
I think it's because some DBs don't implement it. SQLite afaik
doesn't have anything like that, and Mysql, only on InnoDB tables
(default from 4.0+, but still).
Plus, it's not always about the data living on tables, running each
delete() allows developers to exploit this, doing something in c
Hi all,
I've been looking at the code for normal object deletion in an attempt
to get the same behaviour for bulk delete. It seems like there is a
lot of logic dedicated to maintaining referential integrity that the
database could be doing (and would probably do more efficiently).
Is there any p
On 1/19/06, tonemcd <[EMAIL PROTECTED]> wrote:
> Didn't realise stripogram was so open to those sort of exploits (I've
> only ever used it to get rid of the stuff that might mangle layout).
> There's obviously more to this than meets the eye.
Here are some interesting resources on the challenges
18 matches
Mail list logo
