Re: The cotent types framework unreasonably limits model name length.

[Richard Campen]

I think a problem with hashing names here is that it would break the whole 
`apps.get_model(, )` functionality that content 
types uses, as the model name stored in the db is not the actual name 
stored in the apps registry (and modifying the registry functionality feels 
like the wrong approach here).

> *contenttypes* should support all backends,  You need to remember about 
DB-restrictions, e.g. we cannot change `ContentType.model` to a `TextField` 
because TEXT columns cannot be used in unique constraints on MySQL. See similar 
discussion  
about `User.last_name`.

I think a key difference with the `User.last_name` example is that Django 
provides a way to avoid this all together by setting a custom User model. 
The ContentType model is much more tightly coupled, so unless we want to 
implement a similar way to override the ContentType model, it feels like we 
aught to be more accommodating with the max_length here.

With this in mind (and my awareness that me hitting this issue was an edge 
case already) perhaps the most straight forward solution would be to leave 
the `model` field as CharField but just set its max_length to 255. This 
would be consistent with the approach taken with `Permission.name` 
. Sort of feels like kicking 
the bucket down the road, but perhaps it is far enough down said road to no 
longer be an issue.

On Wednesday, 12 August 2020 05:51:58 UTC+12, charettes wrote:
>
> > Suffix-hashing long names like Simon suggests may not be 
> backwards-compatible. 
>
> Could you elaborate on that?
>
> Assuming model names > 100 characters never worked wouldn't only 
> suffix-hashing model names > 100 characters be backward compatible?
>
> Simon
>
> Le mardi 11 août 2020 à 12:05:46 UTC-4, Shai Berger a écrit :
>
>> AFAIK Postgres, in these cases, simply truncates the name. This means: 
>>
>> 1) Generating models with names longer than 63 characters on postgres 
>> is fragile. You may find yourself with more than one model trying to 
>> use the same table name. 
>>
>> 2) Suffix-hashing long names like Simon suggests may not be 
>> backwards-compatible. 
>>
>> My 2 cents, 
>> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/57e57ee9-cc45-46bc-b205-fb87173109c5o%40googlegroups.com.

Re: The cotent types framework unreasonably limits model name length.

[Richard Campen]

> You should be able to work around this for now with a migration in your 
own app that uses RunSQL to alter the column for ContentType.model.

I tried this approach however the ORM level field validation still kicks as 
it still expects VARCHAR 100 even if the db column is now a different type.

On Tuesday, 11 August 2020 20:52:17 UTC+12, Adam Johnson wrote:
>
> It does seem unreasonable. I think a migration to TextField would be 
> warranted.
>
> You should be able to work around this for now with a migration in your 
> own app that uses RunSQL to alter the column for ContentType.model.
>
> On Tue, 11 Aug 2020 at 04:26, Richard Campen  > wrote:
>
>> I guess I have two answers to that:
>>
>> 1) Specifically, in this instance I am scripting the creation of a whole 
>> bunch of Django models as there are too many to do manually. A couple out 
>> of the hundred or so models have names that are just over 100 characters 
>> (102, 103, etc) which is where I found this limit.
>>
>> 2) More generally, why should Django impose any kind of limit at all on 
>> the model length? If python doesn't impose a limit on class names, and the 
>> db backend doesn't limit it, (and even the Django ORM doesn't limit it) why 
>> should a contrib package like content types limit it? Also to preempt the 
>> question, yes I need content types as it is required by other things 
>> running in the application.
>>
>> Side note: If Django truly wishes to limit the Model Name length, doing 
>> so directly would be more appropriate in the model metaclass, rather than 
>> as a side effect of a content types.
>>
>> Cheers
>> R
>>
>>
>> On Tuesday, 11 August 2020 15:19:00 UTC+12, Uri wrote:
>>>
>>> How can a class name be more than 100 characters? Can you give an 
>>> example?
>>>
>>> A limit of 100 characters seems reasonable to me, maybe even 60 would be 
>>> enough.
>>>
>>> אורי
>>> u...@speedy.net
>>>
>>>
>>> On Tue, Aug 11, 2020 at 6:06 AM Richard Campen  
>>> wrote:
>>>
 Hello

 I have hit what I feel is an arbitrary limit on the length of a django 
 model class name. I am using the PostgreSQL backend, which smartly 
 truncates table names above a certain size (normally 63 characters) which 
 means in theory a table name can be of indeterminate length, as PostgreSQL 
 will truncate it appropriately. However, if the model class name is 
 greater 
 than 100 characters than an error is thrown when saving the model name to 
 the `django_content_type` model as the `ContentType.model` field uses a 
 CharField with a limit of 100. This arbitrarily restricts the size of the 
 model name when the db backend can handle it fine.

 I tried to go back in time to figure out if there was any context in 
 setting the `ContentType.model` field max_length at 100 chars, but it was 
 made before the Django project was migrated to git.

 I feel it would be best to switch this field to a TextField, as even 
 255 characters seems an unreasonable limit to impose when the db backend 
 can support longer names, though perhaps having a smaller (but 
 configurable) max_length on the TextField would still be desirable.

 What are peoples feelings on this?

 Cheers,
 Richard

 -- 
 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-d...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/26478a0a-5809-449f-b17d-d7223e2cfb3do%40googlegroups.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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/396d07c8-060d-4d35-98eb-e5bbea502a24o%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b3f9e0bc-85d1-407a-9a4a-2e3f338dbaa5o%40googlegroups.com.

Re: The cotent types framework unreasonably limits model name length.

[charettes]

> Suffix-hashing long names like Simon suggests may not be 
backwards-compatible. 

Could you elaborate on that?

Assuming model names > 100 characters never worked wouldn't only 
suffix-hashing model names > 100 characters be backward compatible?

Simon

Le mardi 11 août 2020 à 12:05:46 UTC-4, Shai Berger a écrit :

> AFAIK Postgres, in these cases, simply truncates the name. This means:
>
> 1) Generating models with names longer than 63 characters on postgres
> is fragile. You may find yourself with more than one model trying to
> use the same table name.
>
> 2) Suffix-hashing long names like Simon suggests may not be
> backwards-compatible.
>
> My 2 cents,
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0a0e59ca-c152-418d-bacc-40526ef956fcn%40googlegroups.com.

Re: DjangoProject

[Michael Ajanaku]

Hello Desh, I would love to collaborate with you.
My Github username is* remiljw*

Thanks.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, Aug 11, 2020 at 6:03 PM Desh Deepak  wrote:

> Hello everyone, I want to developing a django project. Who wants to
> collaborate to do a project and learn django share your github user id for
> github reposetory access.
>
> Live on Heroku
> http://kidszania.herokuapp.com/
>
>
> Thanks
> Desh Deepak
> +91 7011101001
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJ0m4xi70WZ9ZsL4nBU3HmNU%2BZ8TLgNgL4BwAfS7%3DhxNZ-SxNg%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAO_iC_UmSxdNga6_Pv%3DS2%2BTjthy36DBUNqTnh4znhvajUmtP9w%40mail.gmail.com.

Re: DjangoProject

[Kushal Neupane]

We can work in a project with few members as a group work.

On Tue, Aug 11, 2020, 22:47 Desh Deepak  wrote:

> Hello everyone, I want to developing a django project. Who wants to
> collaborate to do a project and learn django share your github user id for
> github reposetory access.
>
> Live on Heroku
> http://kidszania.herokuapp.com/
>
>
> Thanks
> Desh Deepak
> +91 7011101001
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJ0m4xi70WZ9ZsL4nBU3HmNU%2BZ8TLgNgL4BwAfS7%3DhxNZ-SxNg%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFWyajWJnv-eV0V%3D2V5b-C7KO3r%3D0Zj%2B3HDEe0NRvEsAi4hp%2Bg%40mail.gmail.com.

Re: DjangoProject

[Gift Balogun]

https://github.com/giftbalogun

On Tue, Aug 11, 2020 at 6:03 PM Desh Deepak  wrote:

> Hello everyone, I want to developing a django project. Who wants to
> collaborate to do a project and learn django share your github user id for
> github reposetory access.
>
> Live on Heroku
> http://kidszania.herokuapp.com/
>
>
> Thanks
> Desh Deepak
> +91 7011101001
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJ0m4xi70WZ9ZsL4nBU3HmNU%2BZ8TLgNgL4BwAfS7%3DhxNZ-SxNg%40mail.gmail.com
> 
> .
>


-- 
*Best Reguards*
*Balogun Gift*

*Website Designer and Developer*
*Phone/Whatsapp: +2347061601790*

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMshajZ875ctQop1pg0EoHTUb%2B5ndAz3Y%3D393W_d9FFTN5D75Q%40mail.gmail.com.

Re: DjangoProject

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/3.0/faq/help/ . This will help you find
people who are willing to support you, and to ask your question in a way
that makes it easy for them to answer.

Thanks for your understanding and all the best,

Adam

On Tue, 11 Aug 2020 at 17:53, Desh Deepak  wrote:

> Hello everyone, I want to developing a django project. Who wants to
> collaborate to do a project and learn django share your github user id for
> github reposetory access.
>
> Live on Heroku
> http://kidszania.herokuapp.com/
>
>
> Thanks
> Desh Deepak
> +91 7011101001
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJ0m4xi70WZ9ZsL4nBU3HmNU%2BZ8TLgNgL4BwAfS7%3DhxNZ-SxNg%40mail.gmail.com
> 
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2V3YyJRgDbchHPEx6XTy8LB7gfqoXhCd%3DN0cSxi%3Dh%3DLg%40mail.gmail.com.

DjangoProject

[Desh Deepak]

Hello everyone, I want to developing a django project. Who wants to
collaborate to do a project and learn django share your github user id for
github reposetory access.

Live on Heroku
http://kidszania.herokuapp.com/


Thanks
Desh Deepak
+91 7011101001

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJ0m4xi70WZ9ZsL4nBU3HmNU%2BZ8TLgNgL4BwAfS7%3DhxNZ-SxNg%40mail.gmail.com.

Re: The cotent types framework unreasonably limits model name length.

[Shai Berger]

AFAIK Postgres, in these cases, simply truncates the name. This means:

1) Generating models with names longer than 63 characters on postgres
is fragile. You may find yourself with more than one model trying to
use the same table name.

2) Suffix-hashing long names like Simon suggests may not be
backwards-compatible.

My 2 cents,
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200811190519.482b0799.shai%40platonix.com.

Re: The cotent types framework unreasonably limits model name length.

[charettes]

I agree this limitation of `contrib.contenttypes` is a bit unexpected. Not 
saying we should lift it but it does seem arbitrary even if having such 
large table names could be considered bad practice.

One approach we could take that doesn't involve any migration is to 
fallback to hashing of the overflowing characters.

That's the approach taken by the ORM when generating identifiers (e.g. 
index names) that might overflow the identifier limit of a backend[0]

Simon
[0] 
https://github.com/django/django/blob/60626162f76f26d32a38d18151700cb041201fb3/django/db/backends/utils.py#L196-L221

Le mardi 11 août 2020 à 05:54:02 UTC-4, Mariusz Felisiak a écrit :

> *contenttypes* should support all backends,  You need to remember about 
> DB-restrictions, e.g. we cannot change `ContentType.model` to a `TextField` 
> because TEXT columns cannot be used in unique constraints on MySQL. See 
> similar 
> discussion  
> about `User.last_name`.
>
> Best,
> Mariusz
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2995ba70-6a19-4f11-a8a0-b62539d923can%40googlegroups.com.

Re: The cotent types framework unreasonably limits model name length.

[Mariusz Felisiak]

*contenttypes* should support all backends,  You need to remember about 
DB-restrictions, e.g. we cannot change `ContentType.model` to a `TextField` 
because TEXT columns cannot be used in unique constraints on MySQL. See similar 
discussion  
about `User.last_name`.

Best,
Mariusz

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3f108453-cedd-4967-a1be-b40e888572fen%40googlegroups.com.

Re: The cotent types framework unreasonably limits model name length.

[Adam Johnson]

It does seem unreasonable. I think a migration to TextField would be
warranted.

You should be able to work around this for now with a migration in your own
app that uses RunSQL to alter the column for ContentType.model.

On Tue, 11 Aug 2020 at 04:26, Richard Campen 
wrote:

> I guess I have two answers to that:
>
> 1) Specifically, in this instance I am scripting the creation of a whole
> bunch of Django models as there are too many to do manually. A couple out
> of the hundred or so models have names that are just over 100 characters
> (102, 103, etc) which is where I found this limit.
>
> 2) More generally, why should Django impose any kind of limit at all on
> the model length? If python doesn't impose a limit on class names, and the
> db backend doesn't limit it, (and even the Django ORM doesn't limit it) why
> should a contrib package like content types limit it? Also to preempt the
> question, yes I need content types as it is required by other things
> running in the application.
>
> Side note: If Django truly wishes to limit the Model Name length, doing so
> directly would be more appropriate in the model metaclass, rather than as a
> side effect of a content types.
>
> Cheers
> R
>
>
> On Tuesday, 11 August 2020 15:19:00 UTC+12, Uri wrote:
>>
>> How can a class name be more than 100 characters? Can you give an example?
>>
>> A limit of 100 characters seems reasonable to me, maybe even 60 would be
>> enough.
>>
>> אורי
>> u...@speedy.net
>>
>>
>> On Tue, Aug 11, 2020 at 6:06 AM Richard Campen 
>> wrote:
>>
>>> Hello
>>>
>>> I have hit what I feel is an arbitrary limit on the length of a django
>>> model class name. I am using the PostgreSQL backend, which smartly
>>> truncates table names above a certain size (normally 63 characters) which
>>> means in theory a table name can be of indeterminate length, as PostgreSQL
>>> will truncate it appropriately. However, if the model class name is greater
>>> than 100 characters than an error is thrown when saving the model name to
>>> the `django_content_type` model as the `ContentType.model` field uses a
>>> CharField with a limit of 100. This arbitrarily restricts the size of the
>>> model name when the db backend can handle it fine.
>>>
>>> I tried to go back in time to figure out if there was any context in
>>> setting the `ContentType.model` field max_length at 100 chars, but it was
>>> made before the Django project was migrated to git.
>>>
>>> I feel it would be best to switch this field to a TextField, as even 255
>>> characters seems an unreasonable limit to impose when the db backend can
>>> support longer names, though perhaps having a smaller (but configurable)
>>> max_length on the TextField would still be desirable.
>>>
>>> What are peoples feelings on this?
>>>
>>> Cheers,
>>> Richard
>>>
>>> --
>>> 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-d...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/26478a0a-5809-449f-b17d-d7223e2cfb3do%40googlegroups.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/396d07c8-060d-4d35-98eb-e5bbea502a24o%40googlegroups.com
> 
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0fCPnYy1E_74x_Rhe95mSb9SK2C_htrL%3D9svysfs64vg%40mail.gmail.com.

Fellow Reports - August 2020

[Mariusz Felisiak]

Week ending August 9, 2020.

Released Django 2.2.15, 3.0.9, and 3.1.

*Triaged:*
https://code.djangoproject.com/ticket/31849 - django-admin startproject 
- Fails to create files after encountering CommandError (wontfix)
https://code.djangoproject.com/ticket/31848 - Support namespaced 
django.contrib.admindocs views. (wontfix)
https://code.djangoproject.com/ticket/31851 - list_filter not working 
with foreign keys (needsinfo)
https://code.djangoproject.com/ticket/31850 - test_extraction_warning 
(i18n.test_extraction.BasicExtractorTests) fails with xgettext 0.21. 
(accepted)
https://code.djangoproject.com/ticket/24782 - Add 
TestCase.assertFormValid (wontfix)
https://code.djangoproject.com/ticket/31854 - Long model names are not 
wrapped in the navigation sidebar. (created)
https://code.djangoproject.com/ticket/31856 - Add block to customize 
nav_ sidebar. (invalid)
https://code.djangoproject.com/ticket/31859 - Admin side_bar showing up 
in models detail pages. (invalid)
https://code.djangoproject.com/ticket/31857 - Admin side_bar showing up 
in login form with django-otp. (invalid)
https://code.djangoproject.com/ticket/31863 - FK field caching behavior 
change between 1.11.x and 2.x (accepted)
https://code.djangoproject.com/ticket/31864 - Session data cannot be 
decoded during the transition to Django 3.1. (created)
https://code.djangoproject.com/ticket/31868 - Plural forms expression 
could be dangerous (duplicate)

*Reviewed/committed:*
https://github.com/django/django/pull/13267 - Fixed #26977 -- Made 
abstract models raise TypeError when instantiating.
https://github.com/django/django/pull/13257 - Refs #31493 -- Replaced 
var with const and let in JavaScriptCatalog template.
https://github.com/django/django/pull/12163 - Used mock.Mock() in 
SMTPBackendTests.
https://github.com/django/django/pull/13265 - Fixed #31831 -- Fixed 
migration operations ordering when adding order_with_respect_to and 
constraints/indexes.

*Reviewed:*
https://github.com/django/django/pull/13173 - Fixed #25513 -- Extracted 
admin pagination to Paginator.get_elided_page_range()

*Authored:*
https://github.com/django/djangoproject.com/pull/1012 - Updated 
download page for 3.1 release.
https://github.com/django/djangoproject.com/pull/1013 - Updated 
robots.docs.txt for Django 3.1.
https://github.com/django/djangoproject.com/pull/1014 - Updated 
docs-related model fixtures for 3.1 release.
https://github.com/django/django/pull/13275 - Fixed #31854 -- Fixed 
wrapping of long model names in admin's sidebar.
https://github.com/django/django/pull/13279 - Fixed #31864 -- Fixed 
encoding session data during transition to Django 3.1. 

Best,
Mariusz

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/40709a87-c345-4c85-9509-f99e74dbf4f9n%40googlegroups.com.