Figure I may as well show the sort of thing I'm thinking wrt. a more
constrained consumer callable interface...
* A callable, taking two arguments, 'message' & 'channels'
* Message being JSON-serializable python primitives.
* Channels being a dictionary of str:channel
* Channel instances expose `
Dear Django Dev,
At Heroku, we have the privilege of seeing an extremely broad range of
customers utilizing tools like Django to build their applications and
companies. One of the things that we’ve seen customers hit, time and time
again when using tools like Django, is integer overflows f
I think this would be a good improvement, and I'd like to see it. I've been
bitten by integers overflowing at least twice I can remember in my career,
which is two times too many.
However, a major thing we'd have to work out is the upgrade path Consider a
simple model:
class Person(Model):
How would this work with generic foreign keys as well? Those migrations
couldn't be automatic.
On 9 Jun 2017 20:43, "Jacob Kaplan-Moss" wrote:
> I think this would be a good improvement, and I'd like to see it. I've
> been bitten by integers overflowing at least twice I can remember in my
> care
My initial thought was to just have this apply to *new* Django applications, if
that's possible.
Running this migration could take quite some time on some larger apps, and
would require a non-trivial amount of time to execute.
--
Kenneth Reitz
> On Jun 9, 2017, at 3:53 PM, Tom Forbes wrote:
However, it should also be noted that those same larger applications are the
ones that are likely to run into this problem eventually, so perhaps forcing
the migration is the best path moving forward.
Interested in hearing thoughts about this.
--
Kenneth Reitz
> On Jun 9, 2017, at 3:54 PM, Ke
I know people hate settings, but what about one for auto id field type?
It would let you handle backwards compatibility, uuid, and bigint...
--
C
On 10 June 2017 5:42:42 AM AEST, Jacob Kaplan-Moss wrote:
>I think this would be a good improvement, and I'd like to see it. I've
>been
>bitten by i
I'm not sure how this could work with migrations. In a sense, it would
involve making the auto-generated primary key "swappable", including
foreign keys that point to it. This sounds like a headache.
I haven't thought of a possible solution since Kenneth floated this idea in
#django-dev yesterd
I don't see it helping once you hit the problem, but like custom user its a
recommendable setting for pre planning
--
C
On 10 June 2017 11:37:04 AM AEST, Tim Graham wrote:
>I'm not sure how this could work with migrations. In a sense, it would
>involve making the auto-generated primary key "s
I might be wrong, but if the default changes, won't the migrations detect
it and migrate it just fine, including foreign keys?
All of my migrations have this:
('id', models.AutoField(auto_created=True, primary_key=True,
serialize=False, verbose_name='ID')),
So everyone would either need to manual
I would love to see this change implemented as well. I have a few models
that would benefit from having a quick entryline at the bottom of the
list_display.
Personally, I think that the first possibility, where only the items that
are in the 'list_editable' tuple would be editable in the blan
11 matches
Mail list logo