Re: Allow querying JSONField with F objects #29769

[Josh Smeaton]

Hi Mani,

No response can mean either the readers here do not have the same problem 
and have no comment, or your implementation does not require much 
discussion. In any case, you could continue with the process by proposing a 
formal patch, and getting someone to review it once it meets the 
requirements for a finished patch.

See https://docs.djangoproject.com/en/dev/internals/contributing/ 
and https://docs.djangoproject.com/en/dev/intro/contributing/

The change should come with tests and documentation.

Regarding your implementation, I'm not thrilled with the requirement for 
users to provide a Cast. If casting needs to occur, it'd be preferable to 
have the interface of JSONF(lookup, output_field), and then wrap self with 
Cast(self, self.output_field).

Is there any particular reason why you chose a separate expression type 
rather than containing the functionality within the existing F expression? 
I'd be keen to hear the pros/cons of each.

On Sunday, 11 November 2018 13:51:57 UTC+11, Mani S wrote:
>
> Hi devs,
> Any update on this? Would like to know your thoughts
>
>
>
>
> Thanks,
> Mani
>
> On Sun, Oct 28, 2018 at 1:28 AM Mani S > 
> wrote:
>
>> Django's F objects does not perform JSON lookups. A ticket has been 
>> raised for the same https://code.djangoproject.com/ticket/29769
>>
>> I have written a customer expression for querying JSONField and
>> * it works!*
>>
>> class KeyTextTransformFactory:
>>
>> def __init__(self, key_name):
>> self.key_name = key_name
>>
>> def __call__(self, *args, **kwargs):
>> return KeyTextTransform(self.key_name, *args, **kwargs)
>>
>> class JSONF(F):
>>
>> def resolve_expression(self, query=None, allow_joins=True, reuse=None, 
>> summarize=False, for_save=False):
>> rhs = super().resolve_expression(query, allow_joins, reuse, 
>> summarize, for_save)
>>
>> field_list = self.name.split(LOOKUP_SEP)
>> for name in field_list[1:]:
>> rhs = KeyTextTransformFactory(name)(rhs)
>> return rhs
>>
>> It is necessary to include Cast in rhs,
>> Sample.objects.filter(jsonfield__lookup__value=Cast(JSONF('value'), 
>> IntegerField())) 
>>
>>
>> Comment ref: https://code.djangoproject.com/ticket/29769#comment:5
>>
>>
>> Note: This is my first contribution in Django source code, any 
>> comments/suggestions would help me learn the process better.
>>
>>
>>
>>
>>
>> Thank you,
>> Mani
>>
>> -- 
>> 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/88f52ca0-ebd9-4139-b88e-9f21292b7603%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/b45f2c10-2285-4585-b303-4fb12de209b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Courier Management System Project

[Dipankar]

Are you planning for open source or your personal project?

On Tue, Nov 13, 2018 at 1:10 AM sakkhar saha 
wrote:

> Dear All,
> I am Sakkhar form Bangladesh. Now I have a project idea. And i am a single
> man. My Project is Courier Management in Djnago. Please help for the idea.
> How i start my project. And How i Design my database table.
> My Project Feature.
>
> 1. User Can Add Your Order and Track his order.
> 2. Admin Can Add Order and Order complete and pending.
> 3. Admin Approve User.
> 4. When user order confirm than user give an email notification.
> 5. And Finally when Admin deliver the order than user give an email
> notification.
>
> --
> 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/f906f3e8-841b-4fc2-a249-ee251db0b6e9%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Warm Regards,
Dipankar B.

-- 
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/CAFdBwp-baen3iUUxhEAT%3DVJ9ocxkepaxriZyz4_K%3DmAUGKQ9jw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Courier Management System Project

[Adam Johnson]

This mailing list is for the development of Django itself, not for support
using Django. Please use the django-users mailing list for that, or IRC
#django on freenode, or a site like Stack Overflow.

On Tue, 13 Nov 2018 at 08:06, Dipankar  wrote:

> Are you planning for open source or your personal project?
>
> On Tue, Nov 13, 2018 at 1:10 AM sakkhar saha 
> wrote:
>
>> Dear All,
>> I am Sakkhar form Bangladesh. Now I have a project idea. And i am a
>> single man. My Project is Courier Management in Djnago. Please help for the
>> idea. How i start my project. And How i Design my database table.
>> My Project Feature.
>>
>> 1. User Can Add Your Order and Track his order.
>> 2. Admin Can Add Order and Order complete and pending.
>> 3. Admin Approve User.
>> 4. When user order confirm than user give an email notification.
>> 5. And Finally when Admin deliver the order than user give an email
>> notification.
>>
>> --
>> 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/f906f3e8-841b-4fc2-a249-ee251db0b6e9%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Warm Regards,
> Dipankar B.
>
> --
> 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/CAFdBwp-baen3iUUxhEAT%3DVJ9ocxkepaxriZyz4_K%3DmAUGKQ9jw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
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/CAMyDDM33Z%2BtK0Hx7W_nrT6TA9QXUcgzSt7ORiUHMNxqKCTiQsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Extending django.contrib.auth.models Group name to be 191 character max_length

[Tim Allen]

Greetings,

Over the past few releases, several CharFields in django.contrib.auth have 
been increased to a max_length of 191: username, first_name, and last_name 
immediately 
come to mind.

See: 
https://groups.google.com/forum/#!msg/django-developers/h98-oEi7z7g/xzjtFMf1BwAJ

I've issued a PR to extend Group.name to the same length 
here: https://github.com/django/django/pull/10627 The original ticket this 
is addressing was from a colleague who was bumping into the limit when 
syncing groups to Django from 
LDAP: https://code.djangoproject.com/ticket/29939

The 191 character limit was chosen to support MySQL index limits.

Can anyone think of a reason not to change Group.name to be max_length=191 
as we have with the other fields?

Regards,

Tim

-- 
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/a9304881-1d2c-4bc7-84aa-cd9715f443ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending django.contrib.auth.models Group name to be 191 character max_length

[johnrp]

If the other fields are also 191, i see no reason not to make the change.  
It should be a non-breaking change.  And Yes i am that colleague...

On Tuesday, November 13, 2018 at 4:52:24 PM UTC+1, Tim Allen wrote:
>
> Greetings,
>
> Over the past few releases, several CharFields in django.contrib.auth 
> have been increased to a max_length of 191: username, first_name, and 
> last_name 
> immediately come to mind.
>
> See: 
> https://groups.google.com/forum/#!msg/django-developers/h98-oEi7z7g/xzjtFMf1BwAJ
>
> I've issued a PR to extend Group.name to the same length here: 
> https://github.com/django/django/pull/10627 The original ticket this is 
> addressing was from a colleague who was bumping into the limit when syncing 
> groups to Django from LDAP: https://code.djangoproject.com/ticket/29939
>
> The 191 character limit was chosen to support MySQL index limits.
>
> Can anyone think of a reason not to change Group.name to be max_length=191 
> as we have with the other fields?
>
> Regards,
>
> Tim
>

-- 
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/1f00582c-452c-4d56-9450-967a31818bea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: skipping elidable migrations

[Dan Watson]

Hi Adam,

All of your suggestions are perfectly valid things to do (and are in fact 
things I've done in the past). This particular project uses data migrations 
fairly heavily, and the developers haven't been particularly good about 
making sure they run cleanly on fresh databases. We are using Django's test 
framework, but a) with migrations disabled for performance reasons and b) 
using --keepdb, which masks these types of problems.

It just got me thinking that if you've gone out of your way to mark an 
operation as basically "safe to delete", it seems unimportant to run them 
during an initial migration. Bad programming aside, it seems like an easy 
performance bump for projects that use these types of operations. I think 
of elidable as a "soft delete" option that gets garbage collected next 
squash. This would just be an optimization step to ignore what is already 
marked for death. Maybe it's not an optimization we want to reason about, 
or maybe it isn't a big enough use case to be worth coding for, but I 
figured I'd put it out there.

Regards,
Dan


On Saturday, November 10, 2018 at 8:13:27 AM UTC-5, Adam Johnson wrote:
>
> Do you have an example? If you're using Django's default testing 
> framework, it normally creates a fresh database, so from the moment a new 
> data migration is written it would be tested with the empty database 
> scenario.
>
> Afaiu it is possible to write RunPython operations in a way that no-ops on 
> empty databases, e.g. starting with the equivalent of "if not 
> Model.object.exists(): return." It is also possible with RunSQL on database 
> backends that support conditional logic around SQL statements,  or they can 
> be easily converted to RunPython using a function that uses 
> cursor.execute(). And if a project develops problems with past migrations, 
> it's always possible to (carefully) edit them to include such conditions.
>
> On Fri, 9 Nov 2018 at 16:11, Dan Watson > 
> wrote:
>
>> Hi All,
>>
>> I was wondering if anyone had any thoughts on an option to the "migrate" 
>> command (--skip-elidable?) that would skip running elidable migrations. The 
>> use case here is that data migrations that build up over time may act on 
>> certain assumptions (existing tables/data) that may not be true when 
>> migrating a new database. It seems that since they were explicitly marked 
>> as able to be deleted when squashing, they would be safe to not run when 
>> creating a new database. Maybe we don't go so far as to make this the 
>> default behavior when migrating a fresh database, but an option would be 
>> nice. I realize you could simply squash your migrations, but that's not 
>> without penalty of code churn, testing, etc. especially when your existing 
>> migration graph is otherwise fine (and performant).
>>
>> If there's some consensus about this being worthwhile, or at least no 
>> strong objections to it, I can take a stab at the implementation.
>>
>> Regards,
>> Dan
>>
>> -- 
>> 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/fba7a58a-444b-4c90-b139-151580423366%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Adam
>

-- 
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/9cbccecc-0831-4c62-869d-ba7ca619ded7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending django.contrib.auth.models Group name to be 191 character max_length

[Aymeric Augustin]

That seems all right to me.

-- 
Aymeric.



> On 13 Nov 2018, at 16:56, joh...@alumni.upenn.edu wrote:
> 
> If the other fields are also 191, i see no reason not to make the change.  It 
> should be a non-breaking change.  And Yes i am that colleague...
> 
> On Tuesday, November 13, 2018 at 4:52:24 PM UTC+1, Tim Allen wrote:
> Greetings,
> 
> Over the past few releases, several CharFields in django.contrib.auth have 
> been increased to a max_length of 191: username, first_name, and last_name 
> immediately come to mind.
> 
> See: 
> https://groups.google.com/forum/#!msg/django-developers/h98-oEi7z7g/xzjtFMf1BwAJ
>  
> 
> 
> I've issued a PR to extend Group.name to the same length here: 
> https://github.com/django/django/pull/10627 
>  The original ticket this is 
> addressing was from a colleague who was bumping into the limit when syncing 
> groups to Django from LDAP: https://code.djangoproject.com/ticket/29939 
> 
> 
> The 191 character limit was chosen to support MySQL index limits.
> 
> Can anyone think of a reason not to change Group.name to be max_length=191 as 
> we have with the other fields?
> 
> Regards,
> 
> Tim
> 
> -- 
> 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/1f00582c-452c-4d56-9450-967a31818bea%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/3105F97F-523E-49A8-A4F2-1947ACF0D736%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.