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

Re: #25897 - managers defined on non-abstract base classes inherited by child classes

[Shai Berger]

On Sunday 07 February 2016 19:47:48 Alex Poleha wrote:
> I apply my condition to default managers indeed and I see no problem here.
> Default manager is just first manager defined on class(or on it's non
> concrete base). It has no additional magic.
> 

Well, I was using wrong terminology, sorry; when I said "default manager" I 
meant the automatic manager supplied by Django when there is no other. Sorry 
about being unclear.

> About your example. I would never have suggested such a thing. And there
> will be no need to redeclare 'objects' manager in Comment class for you
> example after applying my patch.
> 

That's all I wanted to be sure of; your example made me think otherwise, and I 
didn't look at the actual code.

Thanks,
Shai.

Admin hstore widget

[Curtis Maloney]

So, I've been working on https://code.djangoproject.com/ticket/25197

I have it as part of my own project, with a view to contributing to core 
once it's polished.


Currently it has basic functionality - a JS widget that fires on load, 
hides the textarea, and produces a table of (name, value, actions).


It records original values for existing keys, so you can "undo" your 
changes.  And I'm just adding detection of duplicate keys.


I also hope to add a "soft delete" so you can mark a key for deletion, 
instead of immediately discarding it...


However, I've run into two problems:

1. I'd like more input on the features people feel are essential.

2. Is there a guide somewhere to styles and markup to be used in admin 
templates?


3. I plan to pull in another icon from FA, but it appears the one we 
currently use for "inline delete" is customised from the original.  Does 
anyone know who made these changes and how?


--
Curtis

--
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/56B7CF18.9010007%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: #25897 - managers defined on non-abstract base classes inherited by child classes

[Shai Berger]

Reading your description again, it seems like you apply the condition to 
default managers as well. Default managers are not "specific to the class they 
are defined on", and I see no problem in their inheritance. In particular:

class BaseComment(models.Model):
... some fields, no manager


class Comment(BaseComment):
... some fields, still no manager

Now, are you suggesting that Comment.objects must be defined explicitly? I find 
that odd.

Shai.

On Saturday 06 February 2016 18:07:22 Alex Poleha wrote:
> Thank you for the suggestion. Pull request is adjusted to give deprecation
> warning instead of raising AttributeError.
> Yes, to silence the warning manager need to be be added to any subclass
> explicitly. It is explained in documentation
>  and-model-inheritance> for ages, so I don't think there would be a problem.
> 
> среда, 3 февраля 2016 г., 19:18:24 UTC+3 пользователь Tim Graham написал:
> > Could this go through a deprecation where any use of the inherited
> > managers to be removed will raise a warning for a couple releases? If
> > anyone is relying on the behavior, they just need to add the managers to
> > any subclasses, correct?
> > 
> > On Wednesday, February 3, 2016 at 9:16:41 AM UTC-5, Alex Poleha wrote:
> >> Hi.
> >> 
> >> According to documentation
> >>  >> rs-and-model-inheritance> managers defined on non-abstract base classes
> >> are not inherited by child classes. In fact they're inherited via
> >> python MRO. I made pull request
> >>  to fix it. I find this
> >> 
> >> inheritance embarrassing due to reasons, explained in documentation:
> >>1. Managers defined on non-abstract base classes are *not* inherited
> >>by child classes. If you want to reuse a manager from a non-abstract
> >>base, redeclare it explicitly on the child class. These sorts of
> >>managers are likely to be fairly specific to the class they are
> >>defined on, so inheriting them can often lead to unexpected results
> >>(particularly as far as the default manager goes). Therefore, they
> >>aren’t passed onto child classes.
> >> 
> >> I also think this example shows some reasons why this inheritance is
> >> embarrasing:
> >> 
> >> class SimpleComment(models.Model):
> >> test_objects = models.Manager()
> >> 
> >> class BaseComment(models.Model):
> >> pass
> >> 
> >> class Comment(BaseComment):
> >> test_objects = models.Manager()
> >> 
> >> print(hasattr(models.SimpleComment, 'objects')) #False
> >> print(hasattr(models.Comment, 'objects'))  #True, we may expect False
> >> here, since 'SimpleComment' gives False in similar sitation.
> >> print(models.Comment.objects.model) #, this manager
> >> is not contributed to 'Comment' class
> >> 
> >> Tim Graham suggests asking if anyone relying on this inheritance and
> >> documentation should be fixed instead. Any suggestions?

Re: Fellow Report - February 6, 2016

[Federico Capoano]

Great work!


On Saturday, February 6, 2016 at 4:27:42 PM UTC+1, Tim Graham wrote:
>
> Triaged
>
> ---
>
> https://code.djangoproject.com/ticket/26162 - Data loss when 
> ManyToManyField refers to the wrong table (accepted)
>
> https://code.djangoproject.com/ticket/26168 - BooleanField is forced to 
> be blank=True (accepted)
>
> https://code.djangoproject.com/ticket/26171 - ForeignKey with 
> db_constraint=False doesn't generate an index on MySQL (accepted)
>
> https://code.djangoproject.com/ticket/26173 - localize_input() shouldn't 
> put thousands separator in boolean values (accepted)
>
> https://code.djangoproject.com/ticket/26170 - ModelAdmin 
> add/change/delete views always run transaction on default database 
> (accepted)
>
> https://code.djangoproject.com/ticket/26177 - Using a Postgres database 
> with TIME_ZONE set to None and USE_TZ set to False causes an exception 
> (accepted)
>
> https://code.djangoproject.com/ticket/26179 - Remove null assignment 
> check for non-nullable foreign key fields (created)
>
> https://code.djangoproject.com/ticket/26180 - Altering unique_together 
> still sometimes missing deleted fields (accepted)
>
> Authored
>
> 
>
> https://github.com/django/django/pull/6092 - Fixed #26176 -- Fixed E123 
> flake8 warnings.
>
> https://github.com/django/django/pull/6093 - Fixed #26175 -- Removed SHA1 
> password hashes in tests.
>
> https://github.com/django/django/pull/6096 - Fixed #26177 -- Fixed a 
> PostgreSQL crash with TIME_ZONE=None and USE_TZ=False.
>
> https://github.com/django/djangoproject.com/issues/629 - Update to 
> elasticsearch 2.0
>
> Reviewed/committed
>
> --
>
> https://github.com/django/django/pull/6054 - Fixed #7923 -- Added links 
> to objects displayed by ModelAdmin.raw_id_fields.
>
> https://github.com/django/django/pull/6035 - Fixed #26124 -- Added 
> missing code formatting to docs headers.
>
> https://github.com/django/django/pull/6060 - Fixed #26152 -- Documented 
> how to avoid django.setup() deadlock in standalone scripts.
>
>
> https://github.com/django/django/commit/62f3acc70a43a3c4f4970839d490ac8ea6c79047
>  
> - Fixed incorrect permissions check for admin's "Save as new".
>
> https://github.com/django/django/pull/6073 - Fixed #26155 -- Skipped URL 
> checks if no ROOTURL_CONF setting.
>
> https://github.com/django/django/pull/5686 - Fixed #11313 -- Made 
> ModelAdmin.list_editable more resilient to concurrent edits.
>
> https://github.com/django/django/pull/5980 - Fixed #23971 -- Added "Has 
> date"/"No date" choices for DateFieldListFilter.
>
> https://github.com/django/django/pull/6037 - Fixed #25731 -- Removed 
> unused choices kwarg for Select.render()
>
> https://github.com/django/django/pull/5193 - Fixed #12405 -- Added 
> LOGOUT_REDIRECT_URL setting.
>
> https://github.com/django/django/pull/5745 - Fixed #25833 -- Added 
> support for non-atomic migrations
>
> https://github.com/django/django/pull/6078 - Fixed #13875 -- Made admin's 
> submit_row template tag pass whole Context.
>
> https://github.com/django/django/pull/6051 - Fixed #26144 -- Warned when 
> dumping proxy model without concrete parent.
> https://github.com/django/django/pull/5745 - Fixed #25833 -- Added 
> support for non-atomic migrations.
>

-- 
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/ff1c7f67-1c29-436e-ab87-1eebbed916bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Index expressions

[Josh Smeaton]

There are many places that expressions can extend to, and I think indexes 
would make a really good candidate. There are a few things that need to 
happen to make this work though.

- create meta.indexes to store { index_name: IndexType('field') }
- internally translate any db_index=True to the appropriate key: val in 
above meta.indexes
- internally translate index_together into meta.indexes
- use compiler to generate the sql
- ensure that migrations handle these new indexes properly

I would also suggest that index names be queried to ensure we're not trying 
to use existing names. Not sure if migrations already do this, but I seem 
to remember something about not being able to track index names. Am I 
totally off base?

This idea would actually make a really good GSoC (or similar..) project. Is 
there much interest from the community in custom indexes?

On Sunday, 7 February 2016 22:11:59 UTC+11, Curtis Maloney wrote:
>
>
> So, in #django recently there was a discussion about adding an index on 
> a date field for just the year. 
>
> I know the idea was raised some time ago, and several ideas on the 
> syntax were expressed.  But most of that focused on different types of 
> indices - not on indexing expressions. 
>
> It occurred to me that with the recent advances in expression syntax, it 
> should be fairly easy to add an indexes list to Meta to define complex 
> expressions. 
>
> Input? 
>
> -- 
> C 
>

-- 
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/384535c0-e095-47a5-b73d-1c60649895c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.