Re: A new setting for custom gettext domains?

[Krzysio Gutkowski]

Personally (I'm the author of this PR) this is useful to me as I am using 
pycountry 
to get currency names in my project, and i can't get the translations to 
load without modifying the structure of that package, which shouldn't 
really be done. 

W dniu wtorek, 28 lipca 2015 20:48:14 UTC+2 użytkownik Tim Graham napisał:
>
> Since adding new settings is sometimes controversial, I wanted to ask for 
> thoughts about this ticket [1] / pull request [2] which proposes a new 
> LOCALE_FILENAMES 
> setting to allow using additional gettext domains besides "django". I don't 
> use translations myself, so thoughts about whether the usefulness of the 
> feature justifies a new setting or if there is some other solution to the 
> problem described in the ticket would be welcome.
>
> [1] https://code.djangoproject.com/ticket/6376
> [2] https://github.com/django/django/pull/5053
>

-- 
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/0144fadd-81c2-4259-96a2-bf10fb78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[elky]

Hi guys,

I'm glad to say I finished work on replacing image icons with font. I used Font 
Awesome  (GPL licence) kit to 
do it.

I'll appreciate if you test new icons in your project and report any issues 
here . You can do it by 
running:
pip install git+https://github.com/elky/django-flat-theme.git@flat-icons 
--upgrade

There are couple of questions I wanna discuss in this thread:

1. Font Awesome kit contains about 600 icons - obviously we don't need all 
of them in Django. I can create small kit which will contain only icons 
that used in the project - it will allow us to save about 70KB. But the 
question is - how to support this kit in future if someone decide to add 
new icons?

2. Do we support IE8 and less? If yes - I'll need to add additional font 
files.

Thank you,
Alex D.

-- 
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/849a70d3-3157-4491-b74e-f504fea891f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Marc Tamlyn]

Font Awesome is not GPL - the code is MIT and the font itself is SIL OFL
both of which are fine to include with Django.

On 29 July 2015 at 12:13, elky  wrote:

> Hi guys,
>
> I'm glad to say I finished work on replacing image icons with font. I used 
> Font
> Awesome  (GPL licence) kit to
> do it.
>
> I'll appreciate if you test new icons in your project and report any
> issues here . You can
> do it by running:
> pip install git+https://github.com/elky/django-flat-theme.git@flat-icons
> --upgrade
>
> There are couple of questions I wanna discuss in this thread:
>
> 1. Font Awesome kit contains about 600 icons - obviously we don't need all
> of them in Django. I can create small kit which will contain only icons
> that used in the project - it will allow us to save about 70KB. But the
> question is - how to support this kit in future if someone decide to add
> new icons?
>
> 2. Do we support IE8 and less? If yes - I'll need to add additional font
> files.
>
> Thank you,
> Alex D.
>
>  --
> 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/849a70d3-3157-4491-b74e-f504fea891f7%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/CAMwjO1F%3D5xHz_ZuJksKFj-naJasd%2Bxm5k70kVgihwpR_eip3ow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Tim Graham]

In https://code.djangoproject.com/ticket/20597 we discussed switching to 
SVG (instead of an icon font) in Django 1.10 when we can drop support for 
IE8. Now that Django 1.9 is slated for December and IE8 support ends the 
next month, I think it might be acceptable to drop IE8 support in 1.9 and 
go with the SVG solution now. What do you think?

Is this a blocker for merging the existing PR (which currently needs a 
rebase and release notes)? I'd think the two issues could be separate 
commits.

On Wednesday, July 29, 2015 at 8:27:56 AM UTC-4, Marc Tamlyn wrote:
>
> Font Awesome is not GPL - the code is MIT and the font itself is SIL OFL 
> both of which are fine to include with Django.
>
> On 29 July 2015 at 12:13, elky > wrote:
>
>> Hi guys,
>>
>> I'm glad to say I finished work on replacing image icons with font. I 
>> used Font Awesome  (GPL 
>> licence) kit to do it.
>>
>> I'll appreciate if you test new icons in your project and report any 
>> issues here . You can 
>> do it by running:
>> pip install git+https://github.com/elky/django-flat-theme.git@flat-icons 
>> --upgrade
>>
>> There are couple of questions I wanna discuss in this thread:
>>
>> 1. Font Awesome kit contains about 600 icons - obviously we don't need 
>> all of them in Django. I can create small kit which will contain only icons 
>> that used in the project - it will allow us to save about 70KB. But the 
>> question is - how to support this kit in future if someone decide to add 
>> new icons?
>>
>> 2. Do we support IE8 and less? If yes - I'll need to add additional font 
>> files.
>>
>> Thank you,
>> Alex D.
>>
>>  -- 
>> 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/849a70d3-3157-4491-b74e-f504fea891f7%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/f9e8f86c-6f32-4a6c-ab47-4e6cff26130b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Andy Baker]

I do a lot of projects with highly customized admins and having the full 
font awesome would be splendid.

One option is to use optional requirements: pip install django[all-icons]
but I don't think Django does this anywhere else so it's probably a big 
leap for a small part of contrib.admin

Maybe all that's is needed is a simple wrapper app that packages the full 
font-awesome on the correct static path and it's as simple as documenting 
it thus:

"If you want all the font awesome icons to be available put this app in 
INSTALLED_APPS after contrib.admin and it will overwrite the minimal icon 
pack with the full one"

On Wednesday, 29 July 2015 12:13:15 UTC+1, elky wrote:
>
> Hi guys,
>
> I'm glad to say I finished work on replacing image icons with font. I used 
> Font 
> Awesome  (GPL licence) kit to 
> do it.
>
> I'll appreciate if you test new icons in your project and report any 
> issues here . You can 
> do it by running:
> pip install git+https://github.com/elky/django-flat-theme.git@flat-icons 
> --upgrade
>
> There are couple of questions I wanna discuss in this thread:
>
> 1. Font Awesome kit contains about 600 icons - obviously we don't need all 
> of them in Django. I can create small kit which will contain only icons 
> that used in the project - it will allow us to save about 70KB. But the 
> question is - how to support this kit in future if someone decide to add 
> new icons?
>
> 2. Do we support IE8 and less? If yes - I'll need to add additional font 
> files.
>
> Thank you,
> Alex D.
>
>

-- 
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/ee879f3f-e57c-49f1-9597-2979942fc02f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Tim Graham]

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.
For more options, visit https://groups.google.com/d/optout.

Re: default values on database level

[Carl Meyer]

On 07/28/2015 11:55 PM, Loïc Bistuer wrote:
> +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).

+1 to this approach. We should not try to conflate Python-level defaults
and db-level defaults into a single kwarg (that way lies madness), nor
implicitly introduce db-level defaults for existing models where Django
never used them historically.

A separate `db_default` kwarg is clear, explicit, and matches precedent
from SqlAlchemy.

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/55B8F1EF.2030501%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

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.

Re: default values on database level

[Marc Tamlyn]

Debatably this situation should throw an error at model validation time -
assuming the expression does error out when trying to build that database.
Otherwise it will error at migrate time.

I would like this - it would be very good for UUID as PK

On 29 July 2015 at 16:42, 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.
> 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.
>

-- 
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/CAMwjO1F_X21yEd8bwaRBEiJASjccAm-RtftJ-9mjgSfn532a-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: default values on database level

[Michael Manfre]

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.
For more options, visit https://groups.google.com/d/optout.

Re: default values on database level

[Andrew Godwin]

My main problem with "defaults in the database" was that the current
"default" kwarg is too expressive for things we can put into a database and
doesn't allow representation of "NOW()", etc. I'd be happy with a
default_db arg with defined semantics and that would just blow up if you
tried to pass a function.

Andrew

On Wed, Jul 29, 2015 at 4:50 PM, 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
> 
> .
>
> 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/CAFwN1uq3qXU_6vrJN%2B4Bu7inQRvoEmPS%2BJyhHX67UW31Scs5%2BA%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
> 
> .
>
> 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]

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

[Loïc Bistuer]

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  
> 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  
> 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_42VFuBVJyKFHMXxpg%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/6708A498-F62B-4651-B52D-B40FD1E47DED%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

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_42VFuBVJyKFHMXxpg%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/6708A498-F62B-4651-B52D-B40FD1E47DED%40gmail.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