On Aug 13, 9:30 am, Russell Keith-Magee
wrote:
> On Thu, Aug 13, 2009 at 12:04 AM, Michael Glassford
> wrote:
>
> Secondly: I'm sensitive to the extent that 'on delete cascade' et al
> are phrased in SQL specific terms. I fully acknowledge the use case -
> what happens to a FK when the object it
On Aug 14, 11:48 pm, Russell Keith-Magee
wrote:
> On Sat, Aug 15, 2009 at 8:09 AM, hcarvalhoalves
> wrote:
>
> > On Aug 13, 9:30 am, Russell Keith-Magee
> > wrote:
> >> On Thu, Aug 13, 2009 at 12:04 AM, Michael Glassford
> >> wrote:
>
> >> Se
On Aug 15, 8:53 pm, Russell Keith-Magee
wrote:
> On Sun, Aug 16, 2009 at 1:45 AM, hcarvalhoalves
> wrote:
>
> > On Aug 14, 11:48 pm, Russell Keith-Magee
> > wrote:
> >> On Sat, Aug 15, 2009 at 8:09 AM, hcarvalhoalves
> >> wrote:
>
> >> >
On Aug 17, 1:11 am, 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(..
On 6 fev, 20:03, Idan Gazit wrote:
> Hey folks,
>
> Splitting off
> fromhttp://groups.google.com/group/django-developers/browse_thread/thread...,
> which has an exhaustive discussion about how django needs to treat
> design work.
>
> In the spirit of taking action, I put together this list with
Maybe I can help Luc? I had similar questions once, because I started
learning Django while deploying with a legacy database.
On 8 fev, 20:31, Luc Saffre wrote:
> You cannot ask user code to not even look at invalid data. I'm
> not allergic to exceptions, but raising an exception when I ask for t
On 10 fev, 12:42, Luc Saffre wrote:
> Thank you, Henrique, for dropping in.
>
> Django's current behaviour is not correct because it forces me to access
> non-nullable FK fields differently than nullable ones. "In Python,
> throwing exceptions for expected outcomes is considered very bad form"
> [
I guess you'll like the jobs abstraction from django-command-
extensions [1]
Besides that, I don't see the need for anything to integrate inside a
single "clean" command. It's not like the management commands provided
by Django are hooks, you can and should be making yours for each
specific need.
"""
class U(models.Model):
name = models.TextField(max_length = 255, blank = False)
name2 = models.TextField(max_length = 255, blank = False)
name3 = models.TextField(max_length = 255, blank = False)
...
data = [U() for x in xrange(10)]
"""
What is this actually trying to test?
Although thumbnails are something *many* sites do, everyone have
wildly different requirements, and therefore, different solutions. Two
simple requirements that vary so much that makes impossible to have a
"standard" for thumbnails:
- The API for making thumbnails. Is it a backend class? Is it a
t
To reinforce the already commented issue:
Werkzeug suffers from the same problem, since it's SecureCookie
implementation pickles data by default.
https://github.com/mitsuhiko/werkzeug/issues/60 (See proof of concept
added)
To unpickle data from an untrusted client by default is a big
potential r
I believe the solution is to actually figure a migration path to move
everything that is non-essential to outside the User model. To
identify a User, it should be enough to have username, password and
permissions, and have the rest of the fields live in a
django.contrib.auth.models.DefaultUserProfi
On 10 nov, 18:05, Paul McMillan wrote:
> > There's no reason to not use JSON by default since it's adequate for
> > most cases where you need to store lightweight data client-side, since
> > it's most useful to use with FormWizard and such, where the fields are
> > easily serialized as strings. If
On 10 nov, 21:21, Anssi Kääriäinen wrote:
> On Nov 10, 10:05 pm, Paul McMillan wrote:
>
>
>
>
>
>
>
>
>
> > > There's no reason to not use JSON by default since it's adequate for
> > > most cases where you need to store lightweight data client-side, since
> > > it's most useful to use with FormWi
On May 12, 9:28 pm, Honza Král wrote:
> Hi,
> last week I was busy during EuroDjangoCon, so I am afraid there was
> close to no progress on actual work. I did however give a talk on the
> topic (see slides at [0]) and got into a few interesting discussions.
> As a result of the latter I would lik
I tried both reopening [1] and filling a new ticket [2], but looks
like I'm doing it the wrong way as they kept being closed. So here I
come asking for help on the list.
On syncdb, contrib.auth will create default permissions for each model
you have (add, change, delete). But the permission names
On May 13, 5:27 pm, Malcolm Tredinnick
wrote:
> On Wed, 2009-05-13 at 13:14 -0700, hcarvalhoalves wrote:
> > I tried both reopening [1] and filling a new ticket [2], but looks
> > like I'm doing it the wrong way as they kept being closed. So here I
> > come asking for
On May 13, 6:12 pm, Michael Radziej wrote:
> Hi Hendrique,
>
> On Wed, May 13, hcarvalhoalves wrote:
> > Even if this can't or doesn't seem right to be done on the current
> > state of Django, I would be grateful for some advice on improving the
> > patch to
18 matches
Mail list logo
