What was the approach Loic has planned? As Marten had an implementation
here [1] just without the locking functionality.
Is all the work related to virtual fields done yet?
[1]
https://github.com/knbk/django/commit/7ac5b58587ea2a153766d1601965734731609cdf
On Jul 24, 2015 7:44 PM, "Tim Graham" wr
Hi,
I am using postgresql and I prefer my VARCHAR columns not to have a length
limit. Is there any particular reason why max_length arg to fields is
required. If for compatibility with other database backends we can have
some sane default if it is None.
--
You received this message because you
I would like to propose making Fields.default to rely on the database
generated defaults where possible. This could be implemented by having
some constants like fields.CURRENT_TIMESTAMP, etc. The tricky part here
is to detect database backend specific capabilities and have a python
equivalent fal
think we should create them by default, instead I propose
> the introduction of a db_default kwarg, which should be either a constant,
> or an expression (e.g.
> db_default=contrib.postgres.functions.TransactionNow).
>
> Cheers,
> Loïc
>
> > On Jul 29, 2015, at 12:04, Po
OK, that makes implementation a lot easier. As the model validation can be
done with Model.check() based on the backend given at that time either when
running the server or makmigrations.
On Wed, Jul 29, 2015 at 11:50 AM, Michael Manfre wrote:
>
>
> On Wed, Jul 29, 2015 at 11:42 AM,
lFunction()', F('column1'), 'NOW()').
On Wed, Jul 29, 2015 at 11:58 AM, Podrigal, Aron
wrote:
> OK, that makes implementation a lot easier. As the model validation can be
> done with Model.check() based on the backend given at that time either when
> running the ser
y
>> considering that there is no performance penalty in doing so with all the
>> databases that I care about. Also considering we want first class virtual
>> field support (and plan on turning existing concrete fields into virtual
>> fields) I don't think it's a big
indeed that's it.
On Wed, Jul 29, 2015 at 12:23 PM, Loïc Bistuer
wrote:
> 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
On Aug 3, 2015 3:36 AM, "Anssi Kääriäinen" wrote:
>
> On Wednesday, July 29, 2015 at 8:05:10 AM UTC+3, Aron Podrigal wrote:
>>
>> I would like to propose making Fields.default to rely on the database
generated defaults where possible. This could be implemented by having
some constants like fields
Have a look at [1] it is a composite field implementation.
[1]
https://groups.google.com/forum/m/#!msg/django-developers/MZUcOE6-7GY/sZkBaHvC8wgJ
[2]
https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst
[3]
https://github.com/django/deps/blob/master/draft/0192-standalone-comp
I'm +1 on this.
On Sep 2, 2015 10:31 AM, "'Hugo Osvaldo Barrera' via Django developers
(Contributions to Django itself)"
wrote:
> Hi,
>
> I've worked on several apps where users don't have a username, and
> instead require a unique email. Every time, I've used a similar custom
> user model which
+1
On Sep 7, 2015 4:56 PM, "Shai Berger" wrote:
> On Monday 07 September 2015 20:09:06 Marc Tamlyn wrote:
> > I agree with Aymeric and Markus that createsuperuser should not validate
> > strength of passwords when DEBUG is on. Having to use a secure password
> for
> > development/test accounts is
I started using django-classy-settings and it works very well for me.
On Sep 7, 2015 8:04 PM, "Josh Smeaton" wrote:
> I don't think removing the default list from the template is the right
> idea. We'd be sacrificing some production users that don't go through
> security options on deployment che
h_optional
On Thu, Jul 30, 2015 at 5:15 AM, Aymeric Augustin <
aymeric.augustin.2...@polytechnique.org> wrote:
> > Le 29 juil. 2015 à 18:25, Podrigal, Aron a
> écrit :
> >
> > I see models as what defines the database ddl and and not a
> representation from a end u
We're not talking about representing all CharFields as TEXT, it is about
choosing a sane length as the default for the varchar datatype. So if you
would not specify max_length, for MySQL it would be varchar(255), for
oracle it would be varchar(4000 / bytes_per_char_for NLS_CHARACTERSET) and
for Pos
ettus wrote:
>
> On Sep 21, 2015, at 2:49 PM, "Podrigal, Aron"
> wrote:
>
> > We're not talking about representing all CharFields as TEXT, it is about
> choosing a sane length as the default for the varchar datatype.
>
> But that means notably diff
en.
[1]
https://github.com/django/django/blob/9a97f847109d377995a2312e3d569a3dad1da677/django/db/models/fields/__init__.py#L1102-L1109
On Mon, Sep 21, 2015 at 8:52 PM, Christophe Pettus wrote:
>
> On Sep 21, 2015, at 5:49 PM, "Podrigal, Aron"
> wrote:
>
> > Different sc
n Mon, Sep 21, 2015 at 10:03 PM, Christophe Pettus
wrote:
>
> On Sep 21, 2015, at 6:12 PM, "Podrigal, Aron"
> wrote:
>
> > The reason for having a max_length set to None, is because that's what I
> want for my database columns to be in Postgres, and for MyS
On Mon, Sep 21, 2015 at 10:26 PM, Christophe Pettus
wrote:
>
> On Sep 21, 2015, at 7:22 PM, Shai Berger wrote:
>
> > I'd solve the "need to specify" issue by setting a default that is
> > intentionally smaller than the smallest (core) backend limitation, say
> 128.
>
> I'd be OK with that. Not
meric Augustin" <
aymeric.augus...@polytechnique.org> wrote:
> Hi Aron,
>
> On 22 sept. 2015, at 03:12, Podrigal, Aron
> wrote:
>
> > And for your concern, there will be a MaxLengthValidator added to the
> validators to validate the users input does not exceed the
Ok, I'll wait for other contributors to react.
On Sep 22, 2015 2:03 AM, "Aymeric Augustin" <
aymeric.augus...@polytechnique.org> wrote:
> On 22 sept. 2015, at 07:57, Podrigal, Aron
> wrote:
>
> We will be using max_length=255 or 128 for the default as Shia prop
Why not creating the index as LOWER(email) and do the lookup as LOWER?
On Nov 23, 2015 6:18 PM, "Carl Meyer" wrote:
> On 11/23/2015 03:52 PM, Carl Meyer wrote:
> ...
> > I suppose the best we could do to ease this would be to add a
> > CreateExtension migration operation in contrib.postgres that,
I'm also in favor of some solution here. I used to raise a ValidationError
with either a particular field if I was able to extract the particular
error via regex matches, or as non_field_errors. That was my best I had
instead of resulting in a 5xx. In most cases for example a unique race
condition,
Like it has been discussed a while ago [1] about adding *db_default*, we
should stick with something similar to that and support updates as well.
My 2 cents here.
I like the idea Anssi has proposed to delegate as much as possible using
expressions. So I would propose similar to what discussed in t
ntribute. Has anyone
> started work on this? If not, I'd like to pick it up.
>
> --
> Owais
>
> On Tuesday, August 4, 2015 at 12:05:33 AM UTC+5:30, Michael Manfre wrote:
>>
>>
>>
>> On Mon, Aug 3, 2015 at 9:25 AM, Podrigal, Aron
>> wrote:
&g
Hi,
While going through the code for ModelBase I came across the following
which I was unable to get it clear from the documentation.
A model inheriting from a concrete model does not inherit the Meta class of
its parent no matter if it has a Meta of its own. However, it does inherit
2 options,
Woop, I forgot the link for [1] Here it comes.
[1]
https://groups.google.com/forum/#!msg/django-developers/QRvSCTM4WDo/Nehuqfb8BgAJ
On Tue, Feb 9, 2016 at 4:26 AM, Aron Podrigal
wrote:
> While going through the code for ModelBase for reviewing [1] it is unclear
> to me when inheriting from 2 Ab
I see this was the intention from the very beginning as documented here
[1], but wasn't my initial take. I guess it is debatable. In any case
updating the documentation to clarify it would be helpful.
[1]
https://github.com/django/django/blob/0c20e88e65b8c2b1d097510ee2d7cfe6b2cf9b97/tests/modelte
Hi,
I worked on supporting bulk_insert for multi table inheritance here [1] I
would like to get some feedback.
bulk_create can be used in one of 2 ways
1) If you already have parent records in the database and want to
bulk_insert into the child table only.
2) There isn't any parent records, and
Hi, I would like to get some help pointing out where is the ideal place to
do these transformations for doing lookups on DateTimeRangeField using
__contains=`datetime`.
I got a basic working solution at
https://github.com/django/django/compare/master...ar45:support_dt_range_contains
I would great
30 matches
Mail list logo
