I’m also +1 on having it as part of core given how prominent Redis is.
I agree with Aymeric that it shouldn’t be Django’s responsibility to provide or
wrap advanced Redis functionalities but I think it would be lovely if we at
least exposed the connection/client as a public API.
Regards,
Loïc
I prefer enforcing .values(alias=F(’something’)), to me
.values(alias=‘something’) reads as the equivalent of
.values(alias=Value(‘something’)).
--
Loïc
> On Aug 20, 2016, at 1:04 AM, Tim Graham wrote:
>
> We now have support for expressions in values()/values_list() -- thanks Ian!
> With t
I’m not too keen on a contrib.pg field. CharField is the base class of many
fields, a __init__ kwarg approach such as max_length=None allows us to reach
those as well.
> On Mar 5, 2016, at 3:05 AM, Marc Tamlyn wrote:
>
> Voting:
>
> 1) should there be a default?
>
> I'm lazy, so I would be h
There is a precedent to this (although it seems to happen at startup time
rather than save time), we loop through all the connections and check that
max_length has a value supported by their backend:
https://github.com/django/django/blob/master/django/db/backends/mysql/validation.py.
I don’t th
I don't think this is a problem, we could validate that the backend supports it
during save then blow up if we detect it doesn't. I think we do that for
truncation on MySQL. If the model specifies something that the db doesn't
support it's a configuration problem, not a user validation problem.
+1
> On Oct 25, 2015, at 23:09, charettes wrote:
>
> Now that Curtis did all the investigation work I think it wouldn't hurt being
> consistent here.
>
> __get__(self, instance, cls=None) and __set__(self, instance, value) look
> like sane defaults to me.
>
> Le samedi 24 octobre 2015 18:36:
> On Oct 1, 2015, at 13:38, Anssi Kääriäinen wrote:
>
> +1 to not requiring all transforms to handle __underscore__ syntax.
+1
> I think what we want to do is allow users choose which syntax they
> prefer. The idea is that Django will support both JSONExtract('data',
> path=['owner', 'other_pet
How about we deprecate contrib.flatpages:
- I see people abuse it all the time (do way more with it than they should)
just because it's in core.
- FlatpageFallbackMiddleware is hardly an example to follow.
- It can easily live as a third-party app.
Thoughts?
--
Loïc
> On Aug 12, 2015, at 05
You could already achieve that by making MyPostgresqlFunction a subclass of
models.Func, I don't think it's worth supporting alternate syntaxes.
Cheers,
Loïc
> On Jul 29, 2015, at 23:05, Podrigal, Aron wrote:
>
> What about db_default allows either a constent eg.
> db_default=contrib.postgres
Hi Aron,
+1 on db defaults as well, I've actually started experimenting on this last
week. It's a bit tricky because migrations do use db defaults in some
operations (and drop them once they are done) so we have to ensure that the new
feature doesn't interfere with them.
However I don't think
Hi Aron,
I'm +1 on addressing this, I often don't care about max_length, but I still
want a terse form representation. In my projects I use a subclass of TextField
that sets a TextInput wiget in its formfield() method. But that's not very
elegant: it requires a custom field for a common use-cas
+1!
Loïc
> On Jul 17, 2015, at 23:30, Andrew Godwin wrote:
>
>
>
> On Fri, Jul 17, 2015 at 11:19 AM, James Bennett wrote:
> One option for declaring an app "unmanaged" could be via AppConfig. That's
> fairly clean, mirrors the way you can already set a model as unmanaged in its
> Meta decl
> On Jun 23, 2015, at 17:24, Aymeric Augustin
> wrote:
>
> I'm against making changes to the version numbers we've already planned for
> and also against 1.10, 1.11 etc. version numbers.
>
> Such numbers can easily break version checks that don't expect this case.
> There's lots of code in t
c API. I've never seen them in the wild.
>
> /Markus
>
> On Mon, Jun 22, 2015 at 11:20:52AM -0400, Michael Manfre wrote:
> >+1. I really don't like the idea of 2.x being odd.
> >
> >On Mon, Jun 22, 2015 at 10:33 AM, Loïc Bistuer
> >wrote:
fice
> a little bit of strict semver, but it give some nice meaning to the version
> numbers.
>
>
> On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
> Thanks Loïc,
>
> On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
> > I've attempted to summar
I've attempted to summarize the history of this thread. Note that I marked as
+1 any generally positive feedback towards a given proposal, please correct if
you feel misrepresented.
# First iteration:
1/ Release every 8 months (previously undefined).
2/ LTS every 3rd releases (previously unde
;
> On Sunday, 14 June 2015 09:58:41 UTC+10, Tim Graham wrote:
> Of course RemovedInDjango19Warning is also in 1.7 and a lot of docs reference
> Django 1.9. I'm not enthusiastic about updating all that.
>
> On Sunday, June 14, 2015 at 1:43:50 AM UTC+2, Loïc Bistuer wrote:
>
>
> On Jun 13, 2015, at 20:43, Tim Graham wrote:
>
> I don't have a strong opinion either way on semver, but I think it's a bit
> late to rebrand 1.9 as 2.0 considering we've release code and docs with
> reference to "RemovedInDjango19Warning". Do you have any thoughts on that? We
> could plan
elay
> features so that they don't first appear in an LTS release (at least, this
> would be a pretty big change in Django development and slow down innovation
> in my view).
>
> On Saturday, June 13, 2015 at 6:25:44 AM UTC-4, Loïc Bistuer wrote:
> I think Collin'
I think Collin's proposal can match semver without additional overhead when LTS
are the final minor releases of any given major branch.
1.8 LTS
2.0 (Drop features from 1.7)
2.1 (Drop features from 1.8 LTS)
2.2 LTS
3.0 (Drop features from 2.0, 2.1)
3.1 (Drop features from 2.2 LTS)
3.2 LTS
That wa
I think we can link https://code.djangoproject.com/ticket/56 to
https://code.djangoproject.com/ticket/14286.
The problem is not so much how to create an UnsignedAutoField or a BigAutoField
which is rather trivial, but how to deal with foreign keys pointing to them and
how to migrate them. As fa
Thanks Philippe for bringing this up.
I'm currently upgrading a large Django app with dozens of dependencies from 1.4
to 1.8, here are some observations:
- Most popular and/or maintained libraries actually supports every Django
version between 1.4 to 1.8. (Many thanks to their maintainers!)
- Li
Hi Thomas,
fields/related.py is begging for a refactor of the existing relational fields,
and ideally we'd build composite fields on top of this refactor.
The ORM has seen huge changes in the recent past: migrations, expressions,
lookups, and last but not least a *public* footprint in Model._
>
> On Feb 25, 2015, at 09:07, Russell Keith-Magee
> wrote:
>
> I have an operating system with a graphical user interface. The developers of
> that operating system spent an immense amount of time developing it,
> polishing it, making it behave in predictable ways, getting keyboard
> access
>From my point of view #24351 is ready for a final sanity check and merging.
--
Loïc
> On Feb 19, 2015, at 10:10, Tim Graham wrote:
>
> 3 issues remain. I haven't confirmed with the owners, but it seems to me
> there may be a good chance to wrap them up tomorrow.
>
>
> #24351 RunPy
t we want?
> On Feb 18, 2015, at 15:41, Aymeric Augustin
> wrote:
>
> 2015-02-18 6:34 GMT+01:00 Loïc Bistuer :
> Another option would be to make the signature `allow_migrate(self, db,
> app_label, model_name=None, **hints)` and to put the model class in the hints
> dict, t
.
--
Loïc
> On Feb 18, 2015, at 11:45, Loïc Bistuer wrote:
>
>
>> On Feb 18, 2015, at 05:18, Andrew Godwin wrote:
>>
>> I am fine with the proposed change to allow better routing of
>> RunSQL/RunPython (though in the RunPython case people can easily do r
> On Feb 18, 2015, at 05:18, Andrew Godwin wrote:
>
> I am fine with the proposed change to allow better routing of
> RunSQL/RunPython (though in the RunPython case people can easily do routing
> inside the python code provided anyway, as you can see the DB aliases there).
True although that
l=None in RunPython/SQL.
>
> On Tuesday, February 17, 2015 at 5:06:24 AM UTC-5, Loïc Bistuer wrote:
> Hi all,
>
> The proposed fix for the release blocker
> https://code.djangoproject.com/ticket/24351 suggests changing the signature
> of the `allow_migrate` database rout
Hi all,
The proposed fix for the release blocker
https://code.djangoproject.com/ticket/24351 suggests changing the signature of
the `allow_migrate` database router.
From:
def allow_migrate(self, db, model):
To:
def allow_migrate(self, db, app_label, model, **hints):
We need to make a design d
developer. I think a fail hard, fail fast approach is better
> for these situations than going along with the possibility of subtle or
> not-so-subtle bugs.
>
> Op donderdag 12 februari 2015 17:59:58 UTC+1 schreef Loïc Bistuer:
> Hi Marten,
>
> Sorry for the late response, it
agers. It can also cause
> silent bugs when the manager's methods don't work as intended but won't raise
> an exception either, which is not a good idea imho.
>
> I think the locking approach would be the easiest and most pragmatic method.
> I think it's st
That's what we've done in Django 1.7 for Form/ModelForm (#19617, #8620), and I
completely agree that it should be possible to shadow fields from abstract
models. The docs even suggest that this may be possible in the future; quoting
the relevant section: "this [shadowing] is not permitted for at
Thanks Markus for the detailed report.
On a conceptual level I think we should aim for:
- django.db.* only relies on get_internal_type().
- django.* only relies on field flags.
To address the immediate regressions I suggest we backport
https://github.com/django/django/pull/4002/files as far bac
> On Jan 20, 2015, at 01:43, Andreas Kahnert wrote:
>
> Hi Loïc,
>
> I agree that we should not discuss about the theoretical aspects too much
> (while I disagree on your distinction, the API difference is just their
> mutability, so unless you refer to python intern algorithms for sort-
>
Hi Andreas,
As Florian pointed out, you can't mutate a tuple, but you can mutate the
settings object, so using a tuple or a frozendict won't buy you much.
Regarding the theoretical perspective, tuples aren't meant to be immutable
lists. Tuples are for heterogenous collections of fixed size (e.g
I'm +1 on this plan, "native" support for wsgi.file_wrapper makes a lot of
sense.
--
Loïc
> On Dec 5, 2014, at 12:33 PM, Collin Anderson wrote:
>
> Hi All,
>
> I'm pretty interested in getting secure and _somewhat_ efficient static file
> serving in Django.
>
> Quick history:
> 2005 - Jaco
37 matches
Mail list logo
