Postgres DateTimeRangeField __contains timestamp

[Podrigal, Aron]

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 greatly appreciate if anyone more familiar with the Lookup API to
have a look and suggest how to implement this. Thank you.


-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-ygFrcABE32RjY4P20-X%3DU-tiBGZsMUiVi15KRBuZp%3DqEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

bulk_create for multi table inheritance support

[Podrigal, Aron]

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 need to create them as well.

In the first case, all database backends can support it. It simply requires
the user to set the `parent_ptr` attributes for all child instances, and
then do  bulk_create.
In the second case it gets tricky and it cannot be supported for all
databases for any model as it requires a way to get all the ids from the
inserted parent records. Postgres is the most flexible in that case and
supports bulk_insert for any table and any type of field because it
supports the RETURNING clause so we can always retrieve the ids for the
inserted rows. For sqlite we can only support bulk_create if the model does
not have a parent with an AutoField.
for MySQL I think we can rely on `LAST_INSERT_ID()` which will return the
first ID out of the rows count inserted, so we can than generate a list of
IDs of `range(last_insert_id, last_insert_id + count_rows)`.

Can anyone confirm if we can rely on MySQL last_insert_id to be consistent
and and without gaps for all records inserted at once?

Thanks.

[1]
https://github.com/django/django/compare/master...ar45:allow_bulk_insert_multi_inheritance


-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yh7SXmC1a3T3RZjdDApdAqo6Op06DsQCqOQ0LhbmVhY5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Model Meta inheriting ordering from abstract models

[Podrigal, Aron]

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/modeltests/model_inheritance/models.py#L17-L101

On Tue, Feb 9, 2016 at 10:29 AM, Tim Graham  wrote:

> Did you try looking through git blame and old tickets to find the reason
> for it? The issue is raised on https://code.djangoproject.com/ticket/11078
> .
>
>
> On Monday, February 8, 2016 at 11:19:02 PM UTC-5, Aron Podrigal wrote:
>>
>> 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, which they are: *ordering* and *get_latest_by*. Even
>> when it has a Meta of its own, as long as those 2 options have not been
>> overridden explicitly. By contrast, inheriting from an abstract model
>> inherits the Meta class of the abstract model when it does not have a Meta
>> class of its own. What I find unclear, is, when a model inherits from an
>> abstract model which defines meta.ordering, if the child model also has its
>> own Meta class, it does not inherit the ordering option from it's parent.
>>
>> Is this by design
>>
>>
>> class AbstractModelWithOrdering(models.Model):
>> name = models.CharField(max_length=255)
>>
>> class Meta:
>> ordering = ['-name']
>> abstract = True
>>
>>
>> class ExtendAbstractModelWithOrdering(AbstractModelWithOrdering):
>> class Meta:
>> db_table = 'extended_abstract_model'
>>
>>
>> class ConcreteModelWithOrdering(models.Model):
>> name = models.CharField(max_length=255)
>>
>> class Meta:
>> ordering = ['-name']
>>
>>
>> class ExtendConcreteModelWithOrdering(ConcreteModelWithOrdering):
>> class Meta:
>> db_table = 'extended_concrete_model'
>>
>>
>>
>>
>> class InheritedOrderingTests(SimpleTestCase):
>> def test_inheriting_from_abstract_with_meta_inherits_ordering(self):
>> self.assertEqual(ExtendAbstractModelWithOrdering._meta.ordering, 
>> ['-name'])
>>
>> def test_inheriting_from_concrete_with_meta_inherits_ordering(self):
>> self.assertEqual(ExtendConcreteModelWithOrdering._meta.ordering, 
>> ['-name'])
>>
>>
>>
>> ==
>> FAIL: test_inheriting_from_abstract_with_meta_inherits_ordering
>> (model_meta.tests.InheritedOrderingTests)
>> --
>> Traceback (most recent call last):
>>   File "/home/aron/django/django_repo/tests/model_meta/tests.py", line
>> 280, in test_inheriting_from_abstract_with_meta_inherits_ordering
>> self.assertEqual(ExtendAbstractModelWithOrdering._meta.ordering,
>> ['-name'])
>> AssertionError: Lists differ: [] != ['-name']
>>
>> Second list contains 1 additional elements.
>> First extra element 0:
>> -name
>>
>> - []
>> + ['-name']
>>
>> --
>> Ran 2 tests in 0.001s
>>
>> FAILED (failures=1)
>>
>>
>> --
>> Aron Podrigal
>> -
>> '101', '1110010', '110', '1101110'   '101', '110',
>> '1100100', '1110010', '1101001', '1100111', '111', '1101100'
>>
>> P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/83659928-1e62-469b-adb4-09dca6e15b6b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.googl

Re: Inheriting from multiple ABCs do not follow the MRO for its abstract Managers

[Podrigal, Aron]

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 Abstract models which define Managers, if the
> concrete model should use the first manager according to the creation
> counter or it should follow the MRO. I would expect the following test to
> pass. I would appreciate if someone can confirm that this is a bug so we
> should open a trac ticket and fix this.
>
>
> @isolate_apps('managers_regress')
> def test_multi_abstract_model_inheritance_manager_mro(self):
>
> from django.db.models.manager import Manager
>
> class Manager1(Manager):
> pass
>
> class Manager2(Manager):
> pass
>
> class AbstractModel1(models.Model):
> custom_manager = Manager1()
>
> class Meta:
> abstract = True
>
> class AbstractModel2(models.Model):
> custom_manager = Manager2()
>
> class ConcreteModel(AbstractModel2, AbstractModel1):
> pass
>
> self.assertIsInstance(ConcreteModel.custom_manager, Manager2)
>  self.assertIsInstance(ConcreteModel._default_manager, Manager2)
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/8e267ae3-bd78-40d7-aceb-bddb3e98e317%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yhS_QhGj5SLryM8Hd3hWBzOOdm%3DS33c3Nmt4twLB%3D6EDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Model Meta inheriting ordering from abstract models

[Podrigal, Aron]

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, which they are: *ordering* and *get_latest_by*. Even when it has
a Meta of its own, as long as those 2 options have not been overridden
explicitly. By contrast, inheriting from an abstract model inherits the
Meta class of the abstract model when it does not have a Meta class of its
own. What I find unclear, is, when a model inherits from an abstract model
which defines meta.ordering, if the child model also has its own Meta
class, it does not inherit the ordering option from it's parent.

Is this by design


class AbstractModelWithOrdering(models.Model):
name = models.CharField(max_length=255)

class Meta:
ordering = ['-name']
abstract = True


class ExtendAbstractModelWithOrdering(AbstractModelWithOrdering):
class Meta:
db_table = 'extended_abstract_model'


class ConcreteModelWithOrdering(models.Model):
name = models.CharField(max_length=255)

class Meta:
ordering = ['-name']


class ExtendConcreteModelWithOrdering(ConcreteModelWithOrdering):
class Meta:
db_table = 'extended_concrete_model'




class InheritedOrderingTests(SimpleTestCase):
def test_inheriting_from_abstract_with_meta_inherits_ordering(self):
self.assertEqual(ExtendAbstractModelWithOrdering._meta.ordering,
['-name'])

def test_inheriting_from_concrete_with_meta_inherits_ordering(self):
self.assertEqual(ExtendConcreteModelWithOrdering._meta.ordering,
['-name'])



==
FAIL: test_inheriting_from_abstract_with_meta_inherits_ordering
(model_meta.tests.InheritedOrderingTests)
--
Traceback (most recent call last):
  File "/home/aron/django/django_repo/tests/model_meta/tests.py", line 280,
in test_inheriting_from_abstract_with_meta_inherits_ordering
self.assertEqual(ExtendAbstractModelWithOrdering._meta.ordering,
['-name'])
AssertionError: Lists differ: [] != ['-name']

Second list contains 1 additional elements.
First extra element 0:
-name

- []
+ ['-name']

--
Ran 2 tests in 0.001s

FAILED (failures=1)


-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yiad%2BOhHQ06giAoaFWEBthkuj4%3DhjUYGHOhpfUx9o9hbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: default values on database level

[Podrigal, Aron]

Hi Owais,

I did not have the time to start any work on this. I'm very much interested
in this and I'd be happy to contribute to this in any way. I'm following
along on the other thread you started [1].


[1]
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/django-developers/BDAlTyJwQeY/tTRKkE_fBwAJ


On Feb 6, 2016 6:31 AM, "Owais Lone"  wrote:

> Hi all, I've a working PR that implements this but in a much inferior way
> https://github.com/django/django/pull/5904
>
> I'm very interested in this and would love to contribute. 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:
>>>
>>> >   - Do we want to allow extending this to defaults that are applied on
>>> every save (automatic database backed modified timestamps for example)?
>>>
>>> +1 for this one too.
>>>
>>
>> This behavior would be a nice step toward computed (readonly) database
>> fields.
>>
>>
>>
>> --
>> GPG Fingerprint: 74DE D158 BAD0 EDF8
>> keybase.io/manfre
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9fd48e92-d35f-4fea-9f27-95b91db895af%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/9fd48e92-d35f-4fea-9f27-95b91db895af%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-ygWdVqXE%2B%2B4R286Jrg2Q75i8j6T-HDiZx8M0JskDrNvow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Review Request] Added support for database delegated fields (like AutoField)

[Podrigal, Aron]

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 the other
thread using updated_at = DateTimeField(db_default=Expression,
db_update=Expression) (I don't like the param name *db_update* but you got
the idea).

Updating existing records. I would opt for leaving out fields which have a
db_update parameter, but still allow to override this behavior by
specifying those fields explicitly instance.save(update_fields=...). And
the same for MyModel.objects.filter().update(**fields) we should not
include so called *auto fields* in the update statement but we should never
leave out a field explicitly specified, (we already have problems how to
change pk values on existing records, and we don't want more behavior like
that).

We should refresh values for records on insert and update using the
RETURNING clause for those databases which support it. And defer fetching
the new value for other databases and for update only, since for insert we
already have to fetch the pk anyway, so we can fetch the other values as
well. An interesting idea like Anssi proposed would be to allow refreshing
values behavior be controlled via the Expression.

For queryset methods like bulk_create and update we can already control
deferring values for fields using *.defer()* and *.only()*. So if one would
really want to save the extra overhead fetching new values from db after
update, this can be done by MyModel.objects.get(pk=instance.pk).update().

I don't like Field(db_computed=True) it adds very minimal control over how
and what that does.

To sum up:

1)  fields should have flags how they are used in insert / update queries.

2)  controlling behavior should be done via Expressions

3) Field api should add 2 attributes *db_default* and *db_update* (perhaps
some better param name)

4) Do not limit overriding save behavior on a per query bases.


[1]
https://groups.google.com/forum/#!msg/django-developers/3mcro17Gb40/NPINCcyyBAAJ


On Feb 6, 2016 6:24 AM, "Owais Lone"  wrote:

> Shai and Ayeric, thank you so much for the feedback. The PR did indeed
> snowball into a much bigger one that I had initially planned. I agree with
> all points except,
>
> > - controlling this behavior in the query rather than in the field
> definition — this avoids the awkward “ignore what the field says” query
> parameter
>
> The main reason this PR exists is to let the fields decide if they should
> be updated/refreshed or not. If we don't define this behavior on the
> fields, then the feature will never work with 3rd party apps as developers
> will have to consciously remember to use some method on query API. For
> example, we could add a pguuid field to postgresql package that sets
> behaves like a normal uuid field but calculates the value using
> postgresql's uuid function. This would only work if the we define the
> preference on the field itself and the query API implicitly respects that.
>
> The minimum public API we would need to make this happen is to add an
> option to the Field class, something like,
>
> > id = models.IntegerField(db_computed=True)
>
> `db_computed` would make django do 2 things, it would implicitly ignore
> the field when updating and inserting and it would auto fetch the value
> from the DB after every insert/update on supported backends. That's it.
> Everything else was added to make this a bit flexible, like to make a field
> behave like this only or INSERT or on UPDATE but I think even having just
> one param that does it for both insert and update would be awesome!
>
> --
> Owais
>
> On Monday, February 1, 2016 at 2:03:26 PM UTC+5:30, Aymeric Augustin wrote:
>>
>> > On 31 janv. 2016, at 22:55, Shai Berger  wrote:
>> >
>> > Your message seems to be confusing the queryset API with the
>> model-instance
>> > API.
>>
>> Oops :-(
>>
>> Anyway, it seems that we agree on:
>>
>> - controlling this behavior in the query rather than in the field
>> definition — this avoids the awkward “ignore what the field says” query
>> parameter
>> - trying not to provide separate APIs for insert and update behavior
>> - improving the save(update_fields=…) API to support inserts as well as
>> updates
>>
>> --
>> Aymeric.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2ac56d4e-9259-4fa6-985b-4311686662b6%40googlegroups.com
> 

Re: Allow impossible model validation (mainly admin and generic forms)

[Podrigal, Aron]

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, when the user will resubmit the form it will have the detailed
validation errors or pass.
On Nov 25, 2015 1:57 PM, "Tim Graham"  wrote:

> Would Django itself ever raise ValidationError in Model.save()?
>
> I wonder how you propose converting something like an IntegrityError from
> the database into an "friendly" exception for the user?
>
> On Wednesday, November 25, 2015 at 9:23:05 AM UTC-5, Vlastimil Zíma wrote:
>>
>> Django assumes that all input data in forms can be validated by
>> `Form.is_valid()` which in some cases is not true. Database contraints,
>> e.g. unique, can fail even though they are checked. An application may
>> require communication with other servers while processing data which can
>> lead to errors. But these conditions are not expected by regular Django
>> form flow and an attempt to handle these cases results in large overriding
>> of default implementation.
>>
>>
>> This topic was previously discussed here
>> https://groups.google.com/d/topic/django-developers/rzjpP0byNQo/discussion,
>> but discussion was mainly based on race condition in unique check. I'd like
>> to reopen the topic because there are other possibilities which may cause
>> the possibility of failure after form validation to become real, especially
>> if network connection is involved.
>>
>>
>> I suggest Django should provide mechanism which allow handling the
>> unexpected failures after form validation, e.g. expect `ValidationError` to
>> be raised by `ModelAdmin.save_model`.
>>
>>
>> I started this discussion as a result of wontfix from
>> https://code.djangoproject.com/ticket/25777.
>>
>>
>> Vlastik
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1db10ddc-eae6-4f17-a596-b8ce1aa8ef1f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yh7HTnVowJx08VVU2dqAk9pSVnd%2B40XXdSeeYnG8LSLbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Case-insensitive email as username

[Podrigal, Aron]

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, if lacking
> > super-user permissions, simply errors out and tells you what SQL you
> > need to run manually as a super-user?
>
> ...and now that I look, it appears we already have the `CreateExtension`
> operation :-) It doesn't appear to do anything special to handle the
> permissions problem. Maybe there's not much useful that can be done.
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/56539EB1.7060802%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yiBge_SxmXUkTBB5U75oXoFmDo2RO4rPh707_ZZE9gbLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Podrigal, Aron]

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 proposed.
>
> Would you mind giving a few hours for other contributors to react? I was
> asleep while you were having this discussion; not every contributor is
> hooked to django-developers, especially technical board members.
>
> BTW how is this handled by integer_ranges on per database backend?
>
> I was asking myself the same question after seeing
> https://code.djangoproject.com/ticket/14094#comment:15. I don’t know;
> perhaps it doesn’t! It’s worth investigating.
>
> --
> Aymeric.
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ECA9C917-6FB8-467B-97DC-9E4FE970BC9B%40polytechnique.org
> <https://groups.google.com/d/msgid/django-developers/ECA9C917-6FB8-467B-97DC-9E4FE970BC9B%40polytechnique.org?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yhdepHYgQ9eUCWwFEtVBsDjA8JbAroOTBGM_ssAxWGhUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Podrigal, Aron]

Aymeric, thanks for clarification, my bad I missed that one. We will be
using max_length=255 or 128 for the default as Shia proposed.

BTW how is this handled by integer_ranges on per database backend? Also,
using checks_framework can we validate this setting?
On Sep 22, 2015 1:49 AM, "Aymeric 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 database
> backends maximum length just like when you set max_length explicitly.
>
> This isn’t possible in a project that uses multiple databases, say
> PostgreSQL and Oracle. The form layer cannot say which length is correct
> because it has doesn’t know in what database the data will be saved.
>
> --
> Aymeric.
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2FF1A3B1-0167-4E52-9F99-EB5BDD6B81C5%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yi_6TK5bB-rd5d7XZJAwyKRPQthS%2BM1C0vZyqVK%2BY1d9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Podrigal, Aron]

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 wild, because I think that having to specify
> max_length is good discipline, but not everyone likes oatmeal, either. :)
>

OK, this satisfies me too.

>
> > I"d make an "unlimited length text field" a new type of field,
> explicitly not
> > supported on MySql and Oracle; and I'd suggest that it can live outside
> core
> > for a while. so we may get an impression of how popular it really is.
>
> We kind of have that: TextField.  The problem is that TextField has very
> different performance characteristics and implementation details on
> PostgreSQL vs MySQL and Oracle.  I don't think we need another: If you know
> you are running on PostgreSQL, you just use TextField, and if you are
> either targeting a different database, or writing one that runs on multiple
> ones, you probably want CharField with a specific length.
>

While this makes sense, the use of TextField is also for the purpose of
having rendered a text widget for ModelForms. So we should allow a
max_length of None for both.


>
> --
> -- Christophe Pettus
>x...@thebuild.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3542EAF7-C2EB-4A4B-94F4-8C7A9EC4AC4E%40thebuild.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yj28u18uT8b0V5DunyfyC2fe5m1ftnTLrfEo8nE3U1UVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Podrigal, Aron]

There is actually another reason to not have to specify a max_length which
was mentioned earlier, is because most of the time you don't care about
that and is just tedious to have to specify that when you can get it to
work without it. Default values has always been here for that reason.

On 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 MySQL I don't care
> about the length too, I always choose varchar(255) just for because it is
> required for the database backend.
>
> Well, that's not a practice I think we need to go to great lengths to
> support.  If you *really* *must* have a VARCHAR field without a length, you
> can always use a migration to strip it off.
>
> --
> -- Christophe Pettus
>x...@thebuild.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/95E76678-2FAB-46B4-B830-0AC877886EE4%40thebuild.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yi2mc4bVompW8kL_QYdr80kWEr42r7sj9pOjnitc%3DV0%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Podrigal, Aron]

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 MySQL I don't care
about the length too, I always choose varchar(255) just for because it is
required for the database backend. And for validation of the max length, I
would argue that just like validating the max I want to validate the min.
In short, I want to have more control on my database schema.

And for your concern, there will be a MaxLengthValidator added to the
validators to validate the users input does not exceed the database
backends maximum length just like when you set max_length explicitly. Also
you can manually provide a validator if your user input validation rule is
to be less than the db maximum length. See [1]. The
MaxLengthValidator should actually only be added if there isn't yet
any MaxLengthValidator explicitly given.


[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 schemas?? Schema will always be different for each database
> backend according to its datatypes.
>
> It means if you specify a CharField without a length, you don't know how
> many characters it can accept without error.  That doesn't seem like
> something we should make a change to accept.
>
> > I really don't understand what your concern is.
>
> The current behavior seems entirely reasonable, and I'm not sure I
> understand what problems it is causing.  Specifying a maximum length on a
> CharField is not just a random habit; it should be done as a way of sanity
> checking the value to a reasonable length.  Sometimes, that's natural to
> the data (there are no 50 character telephone numbers or 5000 character
> email addresses), sometimes it's just a way of making sure that something
> bad doesn't get into the database.
>
> --
> -- Christophe Pettus
>x...@thebuild.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/15D5715A-3EF5-4CC0-830C-8EB714424335%40thebuild.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yjm-wLsR4neSjM5q_-9d5LNOfDXUmnyAan1zB2emdR%3D_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Podrigal, Aron]

Different schemas?? Schema will always be different for each database
backend according to its datatypes. I really don't understand what your
concern is. In any case your free to specify a max_length=N where it will
be the same for all backends.

On Mon, Sep 21, 2015 at 8:42 PM, Christophe Pettus  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 different schemas on different backends, for not an
> obvious gain.  What's the benefit there?
>
> --
> -- Christophe Pettus
>x...@thebuild.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/FE33D41D-30F7-497F-9E2D-4ABC396E4BE6%40thebuild.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yg%2Be6Oco8D74Fd1K4QWrZwv8itp5nNZc75y3uoDiKMmwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Podrigal, Aron]

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 PostgreSQL it would be just VARCHAR without a length.

I would like some comments / help for how to compute the size of the string
in bytes for Oracle. unless we can opt for using a default length of 255
for all database backends besides postgres.

On Mon, Sep 21, 2015 at 2:46 PM, Christophe Pettus  wrote:

>
> On Sep 21, 2015, at 9:54 AM, 'Tom Evans' via Django developers
> (Contributions to Django itself) 
> wrote:
> > I'm slightly worried from a DB point of view.
>
> I have to agree, even speaking as PostgreSQL geek.  While VARCHAR and TEXT
> are implemented the same way in PostgreSQL, conceptually they're different
> things.  I don't think the relatively modest benefit of having no default
> justifies the problems that result on other platforms.
>
> --
> -- Christophe Pettus
>x...@thebuild.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/DA725AF8-A7CA-449F-B92A-0BCCDB124AD6%40thebuild.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yiKv1iop5nJ%2BkH444L4iJKCATHt%2Bdkd%3DFiC872mgYUVmA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Podrigal, Aron]

Iv'e started to work on this ticket [1] today and here [2] is my work so
far. I'd appreciate some feedback on the implementation.
There are a couple ways to handle the database type length.

1) Separate types one with a length spec and one without (as mentioned
by Ben Davis in the ticket)
2) Some interface to get the type length specs (the approach I took)

The second option more generic, and provides an interface for any type to
specify a length or scale precision.

[1] https://code.djangoproject.com/ticket/14094
[2]
https://github.com/django/django/compare/master...ar45:max_length_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 users perspective.
>
> Django models do a bit more than this: see the `validators` argument,
> EmailField, etc.
> > And I see the tight coupling between the 2 improper.
>
> I understand your perspective; it's a trade-off between purity and
> convenience and the optimal answer depends on each project.
> > For me I rarely use the builtin generated widgets, I use restframework
> so all I'm interested in a model is for db definition in a highly
> customizable way.
>
> Please make sure your proposals also account for the various way Django
> can be and has been used :-)
>
> --
> Aymeric.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2A451482-2DDD-42CE-895B-55E1FF1026D3%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yhpwRu2iwRU5TDf3NGbvVAYEnJPorjn3tAON0CHuTPEOg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation in Django revisited

[Podrigal, Aron]

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 checklists to better support development
> environments where the security issue (probably) isn't present. I do think
> we need some kind of solution though, because I don't want these validators
> in development either. Personally, I have no issue with adding a SETTING=[]
> to my local_settings. It would be nicer to drive a solution based on DEBUG
> though.
>
> Cheers
>
>
> On Tuesday, 8 September 2015 09:26:36 UTC+10, Tim Graham wrote:
>>
>> I think the simplest solution could be to remove the default list of
>> AUTH_PASSWORD_VALIDATORS that have been added to the project template
>> settings file and let the user add it to their own production settings
>> instead. Do you think this reduces the usefulness of the feature? We could
>> add a deployment check for an empty AUTH_PASSWORD_VALIDATORS as an
>> alternate way of encouraging its use.
>>
>> On Monday, September 7, 2015 at 5:40:58 PM UTC-4, Aron Podrigal wrote:
>>>
>>> +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 an unnecessary level of interference for
 > users.
 >
 > I agree its safer to prevent using admin/admin in production and this
 is a
 > good thing, but there's no reason to prevent this for development. In
 fact,
 > I'd argue enforcing it for development will encourage teams to have a
 > "standard" secure password for their sites, which is also used in
 > production. By allowing admin/admin in development, and enforcing
 something
 > better in production we are more helpfully enforcing best practice.
 >
 +1.

 Shai.

>>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1aba1352-89ba-4cfe-a789-77430c504026%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yin%2BZk9uSkjYUm3V-3a437gMYHjvu24szkThNs75kKxCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation in Django revisited

[Podrigal, Aron]

+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 an unnecessary level of interference for
> > users.
> >
> > I agree its safer to prevent using admin/admin in production and this is
> a
> > good thing, but there's no reason to prevent this for development. In
> fact,
> > I'd argue enforcing it for development will encourage teams to have a
> > "standard" secure password for their sites, which is also used in
> > production. By allowing admin/admin in development, and enforcing
> something
> > better in production we are more helpfully enforcing best practice.
> >
> +1.
>
> Shai.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yiD3PYCWzMQOV8ixG%2BM0LXC7Oa2R7-jDCbkxr%2BfkUT%2B5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: AbstractUser hierarchy and email-based-users

[Podrigal, Aron]

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 extended AbstractBaseUser, PermissionsMixin. I then had
> to copy-paste several fields from AbstractUser into my custom user
> (either because they're always used, or required by the admin).
>
> There are other hacks, and workarounds for email-based accounts (when a
> project doesn't want/need usernames), and I feel that there's room for
> improvement here (rather than just recommending some other hack).
>
> Currently, the User class hierarchy is something like
>
> ... > AbstractBaseUser > AbstractUser > User
>
> If a project does not want their Users username-based, they need to
> extend from AbstractBaseUser (and PermissionsMixin), and copy some
> functionality from AbstractUser. This is a pretty common scenario, and a
> quick search on SO will prove lots of people come across this scenario.
>
> I'd like to propose moving is_active, is_staff, email_user, and a few
> other fields to a Mixin. Then, have AbstractUser extend this mixin too.
> This does not affect our current User model, but allows custom user
> models to simply extend this mixin and have admin-compatible User right
> away.
>
> With this change, and some updates to the documentation, this would
> remove a lot of burden for maintainer of custom user models where
> system's don't require/want username.
>
> I'm willing to work on this too (especially since this would let me
> clean up a lot of custom user models), but I'd like to know if these
> changes would be acceptable or not, or if there's any feedback on it
> first.
>
> Cheers,
>
> --
> Hugo Osvaldo Barrera
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1441186269.1688715.372548137.5D9044C1%40webmail.messagingengine.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yhCEF0rEcN6cWy%3DgWpgKE-uKw29vmVkq3ch8Smby0rSaQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: The hypothetical models.MultiField: is there a rationale to avoid it ? Or could it make it into future releases ?

[Podrigal, Aron]

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-composite-fields.rst
On Aug 20, 2015 10:31 AM,  wrote:

>
>
> Le mardi 18 août 2015 01:36:28 UTC+2, Tim Graham a écrit :
>>
>> I think the general idea is captured in ticket #5929 -- Allow Fields to
>> use multiple db columns (complex datatypes). Is that the gist of your
>> proposal?
>>
>
> Thank you for this link! It seems to discuss the same end result as what I
> tried to present in my first message: the ability to have a single
> models.Field managing an arbitrary number of DB columns under the hood.
>
> The proposed approach is perhaps a bit different: if I understood the
> ticked correctly, it proposes to change the base Field class to make it
> possible, when deriving from it, to manage one or several DB columns. My
> first idea was more to mimic the composite pattern implementation already
> in use with forms.MultiValueField:
> * The models.Field *leaf* classes would still manage a single DB column.
> * Introduce a models.MultiField class, which is a container of
> models.Field classes (be it leaf classes or other MultiField classes). This
> container would address the multiple columns indirectly, through the
> interface of the composing fields. And, to the eyes of the rest of the
> code, it would behave as a normal field, notably offering the to_python()
> feature, hiding the composition in its implementation details.
>
> I did not take time yet to try and assemble a prototype of this idea; In
> fact, I first wanted to confirm if such approach has not already been
> rejected in the past, before investing work in it ;)
>
> Does it sound like a feasible/interesting idea ? Or is there a good reason
> not to do it / too many obvious technical complications that I did not
> foresee ?
>
> Thank you for reading,
>   Ad
>
>
>> https://code.djangoproject.com/ticket/5929
>>
>> On Monday, August 17, 2015 at 5:11:01 AM UTC-4, boito...@gmail.com wrote:
>>>
>>> Hi,
>>>
>>>   While implementing  our collection management system based on Django,
>>> we are always excited by the extensibility of the framework.
>>>   Most recently, we were exposed to the *forms.MultiValueField* and*
>>> widgets.MultiWidget*, that seem to offer composition capacities to
>>> users of the *form* and *widget* layers. Yet, we did not find any
>>> equivalent in the *model* layer, which seemed a bit surprising knowing
>>> that those 3 layers can work hand-in-hand very easily
>>>
>>>   Is there a rationale to prevent implementation of such a
>>> models.MultiField class ? It could be a wrapper around the composite
>>> pattern in the *model* layer, allowing users to easily define custom
>>> models.Field that would leverage existing *models.Field* classes, by
>>> assembling them for specific purposes (while maximizing reuse).
>>>
>>> 
>>>
>>> This question was also raised in Stack Overflow here:
>>> http://stackoverflow.com/q/32014748/1027706. Below is a summary of the
>>> question's example motivating such feature request:
>>>
>>> Imagine we want to store partial date in the DB (i.e., a date that is
>>> either complete , or just month+year, or just year). We could model it in
>>> the models layer using a *models.DateField* + a *models.CharField*
>>> (this last field storing whether the date is complete, or month+year, or
>>> just year).
>>>
>>> Now, if we move to the forms layer, let's say we want a custom
>>> validation step that when a date is partial, the "unused" part of the
>>> DateField must be the value '1'. Because a *ModelForm* automatically
>>> maps one *forms.Field* to each *models.Field*, this constraint would
>>> require a cross-field validation.
>>>
>>> On the other hand, if there was a *models.MultiField*, one could define
>>> a *PartialDate* class to inherit from said *MultiField*. It would then
>>> be seen by other layers as a single *models.Field* (implemented by
>>> aggregating two other *models.Field*, but that would be an
>>> implementation detail hidden from other layers). In *ModelForm*, this
>>> single *models.Field* would map a to a single custom* forms.Field* (probably
>>> deriving from *forms.MultiValueField*), and the validation step above
>>> would not need to be a cross-field validation anymore (more precisely, this
>>> validation could now happen at the *forms.MultiValueField* level,
>>> instead of the *Form* level). With this approach, it seems that the
>>> *models.PartialDate* and the *forms.PartialDate* could be written once,
>>> and reused in as many models and applications as possible, thus respecting
>>> Django's DRY philosophy.
>>>
>>> 
>>>
>>> Could a prototype implementation of such composite model field be of
>>> interest ?
>>>
>>>
>>> --
> You received this message because you are subscribed to the Goog

Re: default values on database level

[Podrigal, Aron]

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.CURRENT_TIMESTAMP, etc.  The tricky part here
is to detect database backend specific capabilities and have a python
equivalent fallback.
>>
>> Any thoughts?
>
>
> A couple of questions about this:
>   - What should happen when you instantiate a new model with DB default,
and show that model to the user in a form. Is the field shown to the user,
and if so, what value should it have?

The field would have no value, so when displayed on the form it would be
blank. A field with blank=False which is included in a form, having a
db_default would be useless.

>   - How to implement actual fetching of the values after save() -
PostgreSQL supports RETURNING, but this is not the case for all databases.

The value would be fetched on demand on its first access, saving a trip to
the database if the field is not accessed. Subsequent updates on that
instance would leave out that field from the list of fields to be updated,
unless its value has been changed on the instance. Maybe we can allow to
handle this based on some parameter provided to save() ?

>   - When is the default applied? On first save of the model, or on model
init time?

Of course on first save, as we want the default value atomically within the
same transaction.

>   - Do we want to allow extending this to defaults that are applied on
every save (automatic database backed modified timestamps for example)?

+1 for this one too.

>
>  - Anssi
>
> --
> You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/f1a7cc68-de1a-49f8-bdf8-ebfaade59955%40googlegroups.com
.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yhtS4xVy4MLoOs%2B0%2B_9AnkZqmpw%2BVmG8pO%3DQ%2Byda01yAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: default values on database level

[Podrigal, Aron]

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 Jul 29, 2015, at 23:05, Podrigal, Aron 
> wrote:
> >
> > What about db_default allows either a constent eg.
> db_default=contrib.postgres.functions. or a string
> "MyCustomPostgresFunction()" and optionaly allowing arguments to be passed
> to the db function optionally also allowing F() expressions by giving a
> tuple db_default=('MyPostgresqlFunction()', F('column1'), 'NOW()').
> >
> > On Wed, Jul 29, 2015 at 11:58 AM, Podrigal, Aron <
> ar...@guaranteedplus.com> 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 server or makmigrations.
> >
> > On Wed, Jul 29, 2015 at 11:50 AM, Michael Manfre 
> wrote:
> >
> >
> > On Wed, Jul 29, 2015 at 11:42 AM, Podrigal, Aron <
> ar...@guaranteedplus.com> wrote:
> > Hi Loic,
> >
> > Agree with having a db_default kwarg.
> >
> > I am not using multiple databases so no experiance with db routers. So
> how would should we handle routing between different databases when the
> db_default value is not compatible with that backend? for example
> Model.save(using='mysql_db') should we than use the Field.default to
> generate the default value (which is not how it works today, that the
> default is computed at instance creation). I would prefer in such a case to
> rely on the database to handle the situation by omitting that field from
> the columns list, so mysql for example would set a non nullable varchar
> column to an empty string, where with other databases it would cause an
> IntegrityError exception. and that db_default and default kwargs cannot be
> used togethor.
> >
> >
> > If db_default is defined for a field, then it should always be used. If
> the db_default is invalid for the configured backend, then it will and
> should break. We shouldn't automatically change db_default to a regular
> default or do any other magic.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to django-developers+unsubscr...@googlegroups.com.
> > To post to this group, send email to django-developers@googlegroups.com.
> > Visit this group at http://groups.google.com/group/django-developers.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAGdCwBsHa%2BGXJSB6fay%3DbM%2B-3qV0y5oSuDNd4m05QM1PPdfKrw%40mail.gmail.com
> .
> >
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> >
> > --
> > Aron Podrigal
> > -
> > '101', '1110010', '110', '1101110'   '101', '110',
> '1100100', '1110010', '1101001', '1100111', '111', '1101100'
> >
> > P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'
> >
> >
> >
> >
> > --
> > Aron Podrigal
> > -
> > '101', '1110010', '110', '1101110'   '101', '110',
> '1100100', '1110010', '1101001', '1100111', '111', '1101100'
> >
> > P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to django-developers+unsubscr...@googlegroups.com.
> > To post to this group, send email to django-developers@googlegroups.com.
> > Visit this group at http://groups.google.com/group/django-developers.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CANJp-yjOW72mXpKHiq-MCWkSHxSC%3DnBA_42VFuB

Re: Making max_length argument optional

[Podrigal, Aron]

I see models as what defines the database ddl and and not a representation
from a  end users perspective. And I see the tight coupling between the 2
improper. Although in most cases the assumptions of representation and
mapping of the 2 is mostly accepted, explicit is better than implicit. Of
course we can have defaults that would work for most cases, but we need a
way to override that. For me I rarely use the builtin generated widgets, I
use restframework so all I'm interested in a model is for db definition in
a highly customizable way.

I would opt for a db_length kwarg which can in turn be used for any field
type eg. Timestamps

On Wed, Jul 29, 2015 at 9:28 AM, Tim Graham  wrote:

> Ticket is https://code.djangoproject.com/ticket/14094
>
> On Wednesday, July 29, 2015 at 1:41:01 AM UTC-4, Loïc Bistuer wrote:
>>
>> 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-case, and
>> it's tightly coupled to Django forms (i.e. won't work with other form
>> libraries and non-HTML forms).
>>
>> Now how we address this depends on the meaning we want to give to models
>> fields like CharField or TextField, more specifically whether the emphasis
>> is on end user's perspective or on mapping 1:1 to database concepts.
>>
>> If we see CharField and TextField as respectively "short/single line
>> field" and "long/multiline field" from a user's perspective, then it makes
>> sense to lift the max_length requirement and use `db_type='TextField'` when
>> max_length is None.
>>
>> However if we want to stay close to their database equivalents, then we
>> could have a display hint on TextField (e.g.
>> TextField(display_multiline=False)) and Field.formfield() would use that
>> hint to provide a TextInput widget instead of a Textarea.
>>
>> Personally I'd much prefer option 1, it's significantly less verbose and
>> more often than not I don't want a length constraint, especially
>> 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 problem to break from the existing
>> models.Field/db types mapping.
>>
>> Cheers,
>> Loïc
>>
>> > On Jul 29, 2015, at 11:27, Podrigal, Aron 
>> wrote:
>> >
>> > 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 are subscribed to the Google
>> Groups "Django developers (Contributions to Django itself)" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to django-develop...@googlegroups.com.
>> > To post to this group, send email to django-d...@googlegroups.com.
>> > Visit this group at http://groups.google.com/group/django-developers.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CANJp-yjwzpk%2BN2%3D4WWbmj5zu2Gwu67G0Sme1f8xQa%2BKrzSQ2Rw%40mail.gmail.com.
>>
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b6d01012-93bb-41b6-9065-c1d360e63b61%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/b6d01012-93bb-41b6-9065-c1d360e63b61%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110' 

Re: default values on database level

[Podrigal, Aron]

What about db_default allows either a constent eg. db_default=
contrib.postgres.functions. or a string "MyCustomPostgresFunction()" and
optionaly allowing arguments to be passed to the db
function optionally also allowing F() expressions by giving a
tuple db_default=('MyPostgresqlFunction()', 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 server or makmigrations.
>
> On Wed, Jul 29, 2015 at 11:50 AM, Michael Manfre 
> wrote:
>
>>
>>
>> On Wed, Jul 29, 2015 at 11:42 AM, Podrigal, Aron <
>> ar...@guaranteedplus.com> wrote:
>>
>>> Hi Loic,
>>>
>>> Agree with having a db_default kwarg.
>>>
>>> I am not using multiple databases so no experiance with db routers. So
>>> how would should we handle routing between different databases when the
>>> db_default value is not compatible with that backend? for example
>>> Model.save(using='mysql_db') should we than use the Field.default to
>>> generate the default value (which is not how it works today, that the
>>> default is computed at instance creation). I would prefer in such a case to
>>> rely on the database to handle the situation by omitting that field from
>>> the columns list, so mysql for example would set a non nullable varchar
>>> column to an empty string, where with other databases it would cause an
>>> IntegrityError exception. and that db_default and default kwargs cannot be
>>> used togethor.
>>>
>>
>> If db_default is defined for a field, then it should always be used. If
>> the db_default is invalid for the configured backend, then it will and
>> should break. We shouldn't automatically change db_default to a regular
>> default or do any other magic.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAGdCwBsHa%2BGXJSB6fay%3DbM%2B-3qV0y5oSuDNd4m05QM1PPdfKrw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAGdCwBsHa%2BGXJSB6fay%3DbM%2B-3qV0y5oSuDNd4m05QM1PPdfKrw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Aron Podrigal
> -
> '101', '1110010', '110', '1101110'   '101', '110',
> '1100100', '1110010', '1101001', '1100111', '111', '1101100'
>
> P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'
>
>


-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yjOW72mXpKHiq-MCWkSHxSC%3DnBA_42VFuBVJyKFHMXxpg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: default values on database level

[Podrigal, Aron]

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, Podrigal, Aron  > wrote:
>
>> Hi Loic,
>>
>> Agree with having a db_default kwarg.
>>
>> I am not using multiple databases so no experiance with db routers. So
>> how would should we handle routing between different databases when the
>> db_default value is not compatible with that backend? for example
>> Model.save(using='mysql_db') should we than use the Field.default to
>> generate the default value (which is not how it works today, that the
>> default is computed at instance creation). I would prefer in such a case to
>> rely on the database to handle the situation by omitting that field from
>> the columns list, so mysql for example would set a non nullable varchar
>> column to an empty string, where with other databases it would cause an
>> IntegrityError exception. and that db_default and default kwargs cannot be
>> used togethor.
>>
>
> If db_default is defined for a field, then it should always be used. If
> the db_default is invalid for the configured backend, then it will and
> should break. We shouldn't automatically change db_default to a regular
> default or do any other magic.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAGdCwBsHa%2BGXJSB6fay%3DbM%2B-3qV0y5oSuDNd4m05QM1PPdfKrw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAGdCwBsHa%2BGXJSB6fay%3DbM%2B-3qV0y5oSuDNd4m05QM1PPdfKrw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aron Podrigal
-
'101', '1110010', '110', '1101110'   '101', '110',
'1100100', '1110010', '1101001', '1100111', '111', '1101100'

P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39'

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yjx%3DKK7HPfZvGVrtDqdDh%3Db2%2BddRAhK%3DzrjPq_iobamhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: default values on database level

[Podrigal, Aron]

Hi Loic,

Agree with having a db_default kwarg.

I am not using multiple databases so no experiance with db routers. So how
would should we handle routing between different databases when the
db_default value is not compatible with that backend? for example
Model.save(using='mysql_db') should we than use the Field.default to
generate the default value (which is not how it works today, that the
default is computed at instance creation). I would prefer in such a case to
rely on the database to handle the situation by omitting that field from
the columns list, so mysql for example would set a non nullable varchar
column to an empty string, where with other databases it would cause an
IntegrityError exception. and that db_default and default kwargs cannot be
used togethor.
On Jul 29, 2015 1:55 AM, "Loïc Bistuer"  wrote:

> 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 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, Podrigal, Aron 
> 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.CURRENT_TIMESTAMP, etc.  The tricky part here
> is to detect database backend specific capabilities and have a python
> equivalent fallback.
> >
> > Any thoughts?
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to django-developers+unsubscr...@googlegroups.com.
> > To post to this group, send email to django-developers@googlegroups.com.
> > Visit this group at http://groups.google.com/group/django-developers.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CANJp-yi5%2Bu%3DW8PdUXtcot%2BO8%3Df35dVLbStwVArJhU7gDnaNXoA%40mail.gmail.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/125BCDAB-728B-4BAA-A8AB-38BA0842B709%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yjsEthdkNQUaUKW3DfgyeigtjyZMYQoGteX%2BQ4MM4uPAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

default values on database level

[Podrigal, Aron]

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 fallback.

Any thoughts?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yi5%2Bu%3DW8PdUXtcot%2BO8%3Df35dVLbStwVArJhU7gDnaNXoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Making max_length argument optional

[Podrigal, Aron]

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 are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yjwzpk%2BN2%3D4WWbmj5zu2Gwu67G0Sme1f8xQa%2BKrzSQ2Rw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: Allow shadowing of abstract fields

[Podrigal, Aron]

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"  wrote:

> Loic indicated the latest approach isn't ideal and said he might work on
> the issue.
>
> https://github.com/django/django/pull/4184
>
> On Friday, July 24, 2015 at 6:59:56 PM UTC-4, Aron Podrigal wrote:
>>
>> Bumping up on this again, what are the plans for moving this ahead.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yjSpv5kXx38-pwvbg%2BohNZR0-76gyO3shitATqmDrswaQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.