Hi!
This week I wrote simple serialization and deserialization for json
format so it's possible now to encode objects from and to json:
import django.core.serializers as s
class Foo(object):
def __init__(self):
self.bar = [Bar(), Bar(), Bar()]
self.x = "X"
class Bar(obje
Good to know about native migrations, and the interim solution seems
reasonable.
Thanks so much!
On Tuesday, June 19, 2012 10:56:38 AM UTC-5, Andrew Godwin wrote:
>
> On 19/06/12 16:13, Greg Aker wrote:
> > Florian:
> >
> > I don't think waiting for migrations in the Django core is totally
>
On 19/06/12 16:13, Greg Aker wrote:
> Florian:
>
> I don't think waiting for migrations in the Django core is totally
> necessary to fix a bug like this (or others that might be similar).
> With proper documentation in the release/upgrade notes, I think it's
> completely reasonable to expect some
On 19/06/12 15:25, Stephan Jaensch wrote:
> Hi Florian,
>
> Am 19.06.2012 um 16:12 schrieb Florian Apolloner:
>
>> Django itself can't change that currently since there is no
>> support for schema alteration in Core. Once we get that we can
>> tackle issues like that and increase to a sensible li
Florian:
I don't think waiting for migrations in the Django core is totally
necessary to fix a bug like this (or others that might be similar). With
proper documentation in the release/upgrade notes, I think it's completely
reasonable to expect someone working with Django to be able to run a m
On 14 kesä, 08:53, Torsten Bronger
wrote:
> Hall chen!
>
> Alex Ogier writes:
> > [...]
>
> > That suggests an idea to me. Perhaps the best way to check this
> > isn't on the way out in the template renderer, but rather on the
> > way back in in the form validation. If the form doesn't get back
>
Hi Florian,
Am 19.06.2012 um 16:12 schrieb Florian Apolloner:
> Django itself can't change that currently since there is no support for
> schema alteration in Core. Once we get that we can tackle issues like that
> and increase to a sensible limit. (both name and codename might cause
> problem
Hi Greg,
Django itself can't change that currently since there is no support for
schema alteration in Core. Once we get that we can tackle issues like that
and increase to a sensible limit. (both name and codename might cause
problems…).
Cheers,
Florian
--
You received this message because y
> On Tue, Jun 19, 2012 at 8:42 PM, Honza Král wrote:
>> I believe exclude is way more useful than fields (I do see the
>> security advantage but in my mind this is the case where convenience
>> beats security, also still afraid of the fields = [f.name for f in
>> ...]).
>
> Personally, I don't thi
Hi,
I'm with Carl in supporting option 3. I think have always thought that
ModelForms were unsafe and requiring the fields option would go a long
way to making them safer. I don't think I'm stupid and I've personally
run into this issue. I have almost *NEVER* run into a case where I
want all field
Thanks Luke for writing this up and representing all views. I am the
proponent of "we are all adults here".
On Thu, Jun 14, 2012 at 6:48 AM, Anssi Kääriäinen
wrote:
> ...
> I hadn't realized all fields present on the Python form but not in the
> HTML form will get overwritten to NULL... The above
I wanted to bring up this bug: https://code.djangoproject.com/ticket/17763
as it's bitten me on a couple of projects recently
Summarizing the ticket:
==
Django automatically generates a name that is longer than what the default
field length can hold.
INSERT INTO "auth_permission"
12 matches
Mail list logo
