Re: Proposal: local timezone-aware datetime fields in the admin site

[Paul Tiplady]

Thanks Aymeric,

A bit of digging gives:

MacOS Chrome: "America/Los_Angeles"
MacOS Firefox: "America/Los_Angeles"
MacOS Safari: "America/Los_Angeles"
Windows Edge: ""America/Los_Angeles"

Do you know what OS/browser combination you were referring to with "Windows 
(which, I'm afraid, has its own time zone name)"?

I haven't got around to testing locales, I'll report back once I do that.

On Wednesday, October 3, 2018 at 11:10:26 PM UTC-7, Aymeric Augustin wrote:
>
> Hello Paul,
>
> Yes, if that works, it would be great.
>
> The API you're pointing to returns a timezone name. This is better than an 
> offset because it avoids being off by one hour when editing dates or times 
> on the other side of the DST change.
>
> You need to check what it does on Windows (which, I'm afraid, has its own 
> time zone name) and whether it's locale-dependent (that would be a mess).
>
> If this API reliably returns a timezone name that pytz understands, then 
> you should be able to achieve your goal in the Widget for datetime fields 
> and to preserve backwards-compatibility.
>
> Best regards,
>
> -- 
> Aymeric.
>
>
>
> On 3 Oct 2018, at 23:04, Paul Tiplady > 
> wrote:
>
> Timezone handling in the Django admin is quite confusing for users when 
> the users are in multiple timezones, because everything in the admin site 
> operates in the server's time.
>
> Assuming USE_TZ=True, TIME_ZONE='UTC', USE_I18N, USE_L10N, when viewing a 
> datetime field, users see the UTC time, with a note below saying "Note: You 
> are 7 hours behind server time". This is better than nothing, but with a 
> modern browser I believe it's possible to improve the situation. 
>
> The ideal behaviour (I believe) would be localizing the timezones in the 
> browser to the user's own time zone, and submitting back to the app using 
> TZ-aware timestamp strings. It's possible to pull the TZ unambiguously from 
> a modern browser: 
> ​https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/resolvedOptions#Browser_compatibility#Description
> .
>
> ```
> Intl.DateTimeFormat().resolvedOptions().timeZone
> ```
>
> Would this approach be acceptable? It seems that we'd want to default to 
> the normal behaviour, and perhaps have this as config on the AdminSite 
> object (since we want a way to enable this globally for sites that wish to 
> use this feature).
>
> (Originally raised here: https://code.djangoproject.com/ticket/29822, 
> posting for discussion)
>
> -- 
> 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/79896a0e-1338-4267-89bd-9904fca4f0d2%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/b668a840-4884-4dc7-908f-32e2a2b493b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Content types shouldn't be created on post_migrate signal

[Marcin Nowak]

Hi Arthur.

BTW: RunPython() is another thing, which can break your migrations, and 
should not be used (especially not by Django internally), because it relies 
on the application layer.

How else can you do a data migration? There is no 
> `migrations.InsertIntoTable`, 
>

You're right. That's why "Insert" should be (in my opinion) introduced. 
Together with "migrations.Delete".

The problem is that data migration based on app layer (python objects, ie. 
Models and Managers here) will cause troubles after some time (when app is 
changing).
In the other words - you cannot rely on your app layer when doing database 
changes. You should never do that, especially for projects requiring LTS.

RunPython() should be used only when you cannot do anything else. In such 
case you must accept all consequences. I'm not against RunPython(), but 
against doing data migrations using it.

The problem with hypothetical "Insert" operation is with mapping field 
types. Insert cannot use Models directly (app layer is changing over a 
time), but should "know" how to map arguments (python types, values) to a 
database literals. It can be achieved by introducing field mapping for a 
every insert or per migration file (something like "model freeze", but only 
for used fields). 

Also Insert should not accept variables calculated in the app layer (within 
a migration) - it should contain only plain/direct data. But using Python 
as a language for migrations, will be hard to avoid such possibility. This 
is important, because database management should not rely on app layer. 
Using variables (i.e. from settings) would result in inconsistent data 
changes between different environments.

the only other way currently would be to run a `migrations.RunSql` query 
> which may look different based on the database used.
>

RunSQL is not the solution for db agnostic operations. It may be only used 
within a project, because db engine used changes rarely (due to the nature 
and importance of the data and relational databases, and systems dependent 
on the db). 
But RunSQL is a handful operation, because SQL is a natural language for db 
management. I'm doing many raw sqls in migrations.
 

> Two things are wrong:
>
>- automatic creation of content types
>
> Why is it wrong to automatically create a content type? 
>

Maybe "automatic" is not a proper word. They should be created 
automatically, but should be applied "at the right time".
 

> Content type is an opt-in feature since you can remove it from 
> `INSTALLED_APPS`.
>

I know, but it is required by contrib.auth. I saw no project depending on 
something else, so CT is optional.. but theoretically ;)
  

>
>- creation of content types after running migrations
>
> That’s the only real problem for me. Maybe using a signal for 
> `migrations.CreateModel` (e.g. post_create_model), instead of using 
> `post_migrate` would fix it, but there may be other scenarios I’m not 
> thinking about.
>

Because signals are related to the app layer and  mixing app and db layers 
together is generally wrong (sorry for wording, please read as "not so 
good"), changing one signal to another is not a good solution.

Before I wrote about the issue, I was doing diagnosis and I was thinking 
about the issue for a while. So I think that the best place for applying 
data changes is a migration.
Django can detect model changes (adding and removals of models, too), so it 
can generate series of inserts or deletes in the right place, to run them *at 
the right time*.

Or if `django.contrib.contenttypes` is only added later on to 
> `INSTALLED_APPS`?


After adding contrib.contenttypes, Django should check existence of 
django_content_type table. If exists, Django should only check for data 
changes and generate series of inserts/deletes. If not, Django should 
generate inserts for all models. If CT is removed later, Django should 
remove all CT data .


CT opt-in should be connected to a signal related to the creation of 
migration files (Autodetector?), not to a signal related to their 
execution. I.e. pre/post_autodection signals should be introduced.


Kind Regards,

Marcin

-- 
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/af22034d-3983-4b19-87b2-256adc1cb11a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Content types shouldn't be created on post_migrate signal

[Arthur Rio]

BTW: RunPython() is another thing, which can break your migrations, and
should not be used (especially not by Django internally), because it relies
on the application layer.

How else can you do a data migration? There is no
`migrations.InsertIntoTable`, the only other way currently would be to run
a `migrations.RunSql` query which may look different based on the database
used.

Two things are wrong:

   - automatic creation of content types

Why is it wrong to automatically create a content type? Content type is an
opt-in feature since you can remove it from `INSTALLED_APPS`.


   - creation of content types after running migrations

That’s the only real problem for me. Maybe using a signal for
`migrations.CreateModel` (e.g. post_create_model), instead of using
`post_migrate` would fix it, but there may be other scenarios I’m not
thinking about.


Solution:

   - creation of new app should add very first migration, which will add
   entry to the content types

How would you handle creating a model later on? Or if
`django.contrib.contenttypes` is only added later on to `INSTALLED_APPS`?


Regards,

—

Arthur


On October 4, 2018 at 1:36:39 PM, Marcin Nowak (marcin.j.no...@gmail.com)
wrote:

Hi Aymeric.

Thank you for your reply.

Unfortunately you wrote mostly about me or my writing style, not about the
issue.
I disagree with your opinion about my comments being passive or aggressive.
I'm always writing about a piece of code, functionality,
design/architecture or bug. I never criticised a person directly.



> Starting with "There is a huge issue with content types framework" isn't a
> good way to motivate them.
>
>
But there is an issue with content types framework (not with it's authors).



> Speaking for myself, I would be more eager to investigate if you skipped
> the hyperbole and remained neutral, for example "I'm facing an issue with
> the content types framework".
>
>
Sorry hearing that. I'm not native English speaker.

For me there is almost no difference with these two sentences, except that
first is about the affected thing ("there is an issue with") and second is
more about me ("I have a problem").
Both are valid, I think. I have a problem which is caused by CT framework's
design or issue (in fact it comes from a historical reason, before
migrations era).


> You'd have more success if you managed to write in a positive style.
>

I don't think that my style is unpleasant. If it is - sorry for that.
I'm always trying to describe the problem and give some proposals.
But I'll try to improve this.


> I think the issue itself is valid. I may have hit it before and worked
> around it, likely be executing a subset of migrations to trigger creation
> of content types, then executing the rest of the migrations. Django could
> probably do better.
>
>
I'll generate CTs in very first migration. This will be a workaround, of
course.
But because Django uses migrations internally, CT's should be added to the
database in a same way.

And RunPython() can be problematic. I did something similar with Liquibase'
executeCommand, which was calling management command. And of course it
caused problems after changing app layer.
I'm very conservative about databases and managing them, I think that there
must be complete separation between db and app layer (in the context of
managing dbs), because app layer is changing frequently (more often than
dbs). Mixing both worlds will cause troubles. Always.

Kind Regards,
Marcin
--
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/0e4464f7-2ed7-4e6b-9b7e-f98a385dffd5%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/CADOBPEGDbxpNnECnZMk-Ff51YX6T3drfm9MTBRS3gxmcEgQ1tg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Content types shouldn't be created on post_migrate signal

[Marcin Nowak]

Hi Aymeric.

Thank you for your reply. 

Unfortunately you wrote mostly about me or my writing style, not about the 
issue.
I disagree with your opinion about my comments being passive or aggressive. 
I'm always writing about a piece of code, functionality, 
design/architecture or bug. I never criticised a person directly.

 

> Starting with "There is a huge issue with content types framework" isn't a 
> good way to motivate them.
>
>
But there is an issue with content types framework (not with it's authors). 

 

> Speaking for myself, I would be more eager to investigate if you skipped 
> the hyperbole and remained neutral, for example "I'm facing an issue with 
> the content types framework".
>
>
Sorry hearing that. I'm not native English speaker. 

For me there is almost no difference with these two sentences, except that 
first is about the affected thing ("there is an issue with") and second is 
more about me ("I have a problem"). 
Both are valid, I think. I have a problem which is caused by CT framework's 
design or issue (in fact it comes from a historical reason, before 
migrations era).
 

> You'd have more success if you managed to write in a positive style.
>

I don't think that my style is unpleasant. If it is - sorry for that. 
I'm always trying to describe the problem and give some proposals. 
But I'll try to improve this.
  

> I think the issue itself is valid. I may have hit it before and worked 
> around it, likely be executing a subset of migrations to trigger creation 
> of content types, then executing the rest of the migrations. Django could 
> probably do better.
>
>
I'll generate CTs in very first migration. This will be a workaround, of 
course. 
But because Django uses migrations internally, CT's should be added to the 
database in a same way.

And RunPython() can be problematic. I did something similar with Liquibase' 
executeCommand, which was calling management command. And of course it 
caused problems after changing app layer. 
I'm very conservative about databases and managing them, I think that there 
must be complete separation between db and app layer (in the context of 
managing dbs), because app layer is changing frequently (more often than 
dbs). Mixing both worlds will cause troubles. Always.

Kind Regards,
Marcin

-- 
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/0e4464f7-2ed7-4e6b-9b7e-f98a385dffd5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a database-agnostic JSONField into Django

[Tom Forbes]

I would also be very interested in helping out. I don’t know if this is
useful, but I’ve had a brief look at the feature support compared to our
current baseline Postgres features:

MySQL: https://dev.mysql.com/doc/refman/8.0/en/json-search-functions.html -
JSON_CONTAINS_PATH() can implement most of our has_* filtering, and we can
also do array index lookups. Will need to convert lookups to path
expressions. There also appears to be some nastiness relating to quoting we
may need to take care of. Also supports partial updating of JSON columns.
The ->> operator can be used for filtering.

Sqlite: https://www.sqlite.org/json1.html - Some trickiness, sqlite
preserves json objects with duplicate keys. Can do simple queries using
json_extract(), but we may need to use json_each() for some lookups (which
adds a bit of complexity). Supports updating values in-place as well.

Oracle:
https://docs.oracle.com/en/database/oracle/oracle-database/18/adjsn/query-json-data.html#GUID–119E5069–77F2–45DC-B6F0-A1B312945590
- Seems to support nesting lookups without needing a path expression,
i.e SELECT
json_field.some_key.some_value FROM table. Supports functions that take
JSON paths as well so perhaps it’s easier to use those. Supports updating
in place.

It seems while all 4 backends support at least the minimum feature set
Postgres does, they do so in pretty different ways (different functions,
different arguments, etc).




On 4 October 2018 at 19:47:03, Adam Johnson (m...@adamj.eu) wrote:

I'd be up for helping with a database-agnostic one. One thing to note about
MySQL world is that MariaDB diverges more from MySQL here and I haven't
found the time to fix the differences here in Django-MySQL's JSONField. I'd
get on with it if I knew someone needed the work for a DB-agnostic field
though ;)

On Thu, 4 Oct 2018 at 12:31, Carlton Gibson 
wrote:

> Sorry, what I meant was a Django field. (I wasn't clear enough.)
>
> Charles Leifer has good posts covering SQLite+JSON
> http://charlesleifer.com/
> His Peewee ORM has a JSONField
> http://docs.peewee-orm.com/en/latest/peewee/sqlite_ext.html#sqlite-ext
>
> I was just wondering if someone knew if someone had already wrapped up a
> Django equivalent?
>
> (If so we'd have reference implementations for all the supported DBs...)
>
> On Thursday, 4 October 2018 13:12:42 UTC+2, Jon Dufresne wrote:
>>
>> > Anyone know of an SQLite implementation?
>>
>> A quick search shows the JSON1 extensions exists:
>> https://www.sqlite.org/json1.html
>>
>> According to the release history (https://sqlite.org/changes.html) this
>> was added in version 3.9.0 (2015-10-14).
>>
>> But I have no direct experience working with it.
>>
>> On Thu, Oct 4, 2018 at 12:19 AM Carlton Gibson 
>> wrote:
>>
>>> This has come up again, with an example implementation for Oracle:
>>>
>>> https://code.djangoproject.com/ticket/29821
>>>
>>> Anyone know of an SQLite implementation?
>>>
>>>
>>>
>>> --
>>> 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/215a0e1c-6947-4375-ba1d-38d310c32411%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/593cb04e-6de6-4ccd-9b8d-d175f95d970f%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

Re: Content types shouldn't be created on post_migrate signal

[Aymeric Augustin]

Hello Marcin,

I assume you're writing to this list because you would like other Django 
contributors to cooperate in order to fix this issue. Starting with "There is a 
huge issue with content types framework" isn't a good way to motivate them.

Speaking for myself, I would be more eager to investigate if you skipped the 
hyperbole and remained neutral, for example "I'm facing an issue with the 
content types framework".

Many of your messages on this mailing list contain strongly negative or 
passive-aggressive comments. They get in the way of communicating your ideas. 
You'd have more success if you managed to write in a positive style.

I think the issue itself is valid. I may have hit it before and worked around 
it, likely be executing a subset of migrations to trigger creation of content 
types, then executing the rest of the migrations. Django could probably do 
better.

Best regards,

-- 
Aymeric.



> On 3 Oct 2018, at 13:01, Marcin Nowak  wrote:
> 
> Hello.
> 
> There is a huge issue with content types framework. The data is loaded after 
> every migration (post_migrate signal) automatically, and this approach is 
> against db data consistency.
> The biggest problem is with data migrations, which are applied at the first 
> time (on clean database). Any data migration which depends on some content 
> types will not insert the data.
> 
> The sequence looks like this:
> create db
> insert into auth_permission ...  inner join django_content_type ...
> post migrate: insert into django_content_type ...
> 
> Two things are wrong:
> automatic creation of content types
> creation of content types after running migrations
> Solution:
> creation of new app should add very first migration, which will add entry to 
> the content types
> create_contentypes handler should be removed from post_migrate signal
> Any data migration, which depends on some content types, should be declared 
> with proper dependency. This will guarantee existence of the required content 
> type entry.
> 
> 
> BR,
> Marcin
> 
> 
> 
> -- 
> 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/8869b1cb-2b92-4e05-823a-92e72308fc23%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/612A03B5-ACF3-4245-95C5-55C90245DCB8%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a database-agnostic JSONField into Django

[Adam Johnson]

I'd be up for helping with a database-agnostic one. One thing to note about
MySQL world is that MariaDB diverges more from MySQL here and I haven't
found the time to fix the differences here in Django-MySQL's JSONField. I'd
get on with it if I knew someone needed the work for a DB-agnostic field
though ;)

On Thu, 4 Oct 2018 at 12:31, Carlton Gibson 
wrote:

> Sorry, what I meant was a Django field. (I wasn't clear enough.)
>
> Charles Leifer has good posts covering SQLite+JSON
> http://charlesleifer.com/
> His Peewee ORM has a JSONField
> http://docs.peewee-orm.com/en/latest/peewee/sqlite_ext.html#sqlite-ext
>
> I was just wondering if someone knew if someone had already wrapped up a
> Django equivalent?
>
> (If so we'd have reference implementations for all the supported DBs...)
>
> On Thursday, 4 October 2018 13:12:42 UTC+2, Jon Dufresne wrote:
>>
>> > Anyone know of an SQLite implementation?
>>
>> A quick search shows the JSON1 extensions exists:
>> https://www.sqlite.org/json1.html
>>
>> According to the release history (https://sqlite.org/changes.html) this
>> was added in version 3.9.0 (2015-10-14).
>>
>> But I have no direct experience working with it.
>>
>> On Thu, Oct 4, 2018 at 12:19 AM Carlton Gibson 
>> wrote:
>>
>>> This has come up again, with an example implementation for Oracle:
>>>
>>> https://code.djangoproject.com/ticket/29821
>>>
>>> Anyone know of an SQLite implementation?
>>>
>>>
>>>
>>> --
>>> 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/215a0e1c-6947-4375-ba1d-38d310c32411%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/593cb04e-6de6-4ccd-9b8d-d175f95d970f%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/CAMyDDM2qz8xTL388_LZ8Eoqnm80bcFt_W%2Bu3axcC%2BC7g52PUHQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a database-agnostic JSONField into Django

[Carlton Gibson]

Sorry, what I meant was a Django field. (I wasn't clear enough.) 

Charles Leifer has good posts covering SQLite+JSON http://charlesleifer.com/
His Peewee ORM has a 
JSONField http://docs.peewee-orm.com/en/latest/peewee/sqlite_ext.html#sqlite-ext

I was just wondering if someone knew if someone had already wrapped up a 
Django equivalent?

(If so we'd have reference implementations for all the supported DBs...)

On Thursday, 4 October 2018 13:12:42 UTC+2, Jon Dufresne wrote:
>
> > Anyone know of an SQLite implementation?
>
> A quick search shows the JSON1 extensions exists:
> https://www.sqlite.org/json1.html
>
> According to the release history (https://sqlite.org/changes.html) this 
> was added in version 3.9.0 (2015-10-14).
>
> But I have no direct experience working with it.
>
> On Thu, Oct 4, 2018 at 12:19 AM Carlton Gibson  > wrote:
>
>> This has come up again, with an example implementation for Oracle: 
>>
>> https://code.djangoproject.com/ticket/29821
>>
>> Anyone know of an SQLite implementation?
>>
>>
>>
>> -- 
>> 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/215a0e1c-6947-4375-ba1d-38d310c32411%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/593cb04e-6de6-4ccd-9b8d-d175f95d970f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a database-agnostic JSONField into Django

[Jon Dufresne]

> Anyone know of an SQLite implementation?

A quick search shows the JSON1 extensions exists:
https://www.sqlite.org/json1.html

According to the release history (https://sqlite.org/changes.html) this was
added in version 3.9.0 (2015-10-14).

But I have no direct experience working with it.

On Thu, Oct 4, 2018 at 12:19 AM Carlton Gibson 
wrote:

> This has come up again, with an example implementation for Oracle:
>
> https://code.djangoproject.com/ticket/29821
>
> Anyone know of an SQLite implementation?
>
>
>
> --
> 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/215a0e1c-6947-4375-ba1d-38d310c32411%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/CADhq2b4dAkdiOeZFxEqGYGj6DYrUrYFVaGT9rewrhVr_Ha%2B3MA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can we remove FILE_CHARSET?

[Vasili Korol]

I guess, my statement doesn't apply if FILE_CHARSET only affects Django 
text files, so disregard. My point was that non-UTF data is still actively 
used despite the fact that "the whole world moved to Unicode".

-- 
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/b79c03f1-cf52-4594-a936-936829921e8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a database-agnostic JSONField into Django

[Carlton Gibson]

This has come up again, with an example implementation for Oracle: 

https://code.djangoproject.com/ticket/29821

Anyone know of an SQLite implementation?



-- 
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/215a0e1c-6947-4375-ba1d-38d310c32411%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: local timezone-aware datetime fields in the admin site

[Aymeric Augustin]

Hello Paul,

Yes, if that works, it would be great.

The API you're pointing to returns a timezone name. This is better than an 
offset because it avoids being off by one hour when editing dates or times on 
the other side of the DST change.

You need to check what it does on Windows (which, I'm afraid, has its own time 
zone name) and whether it's locale-dependent (that would be a mess).

If this API reliably returns a timezone name that pytz understands, then you 
should be able to achieve your goal in the Widget for datetime fields and to 
preserve backwards-compatibility.

Best regards,

-- 
Aymeric.



> On 3 Oct 2018, at 23:04, Paul Tiplady  wrote:
> 
> Timezone handling in the Django admin is quite confusing for users when the 
> users are in multiple timezones, because everything in the admin site 
> operates in the server's time.
> 
> Assuming USE_TZ=True, TIME_ZONE='UTC', USE_I18N, USE_L10N, when viewing a 
> datetime field, users see the UTC time, with a note below saying "Note: You 
> are 7 hours behind server time". This is better than nothing, but with a 
> modern browser I believe it's possible to improve the situation. 
> 
> The ideal behaviour (I believe) would be localizing the timezones in the 
> browser to the user's own time zone, and submitting back to the app using 
> TZ-aware timestamp strings. It's possible to pull the TZ unambiguously from a 
> modern browser: 
> ​https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/resolvedOptions#Browser_compatibility#Description
>  
> .
> 
> ```
> Intl.DateTimeFormat().resolvedOptions().timeZone
> ```
> 
> Would this approach be acceptable? It seems that we'd want to default to the 
> normal behaviour, and perhaps have this as config on the AdminSite object 
> (since we want a way to enable this globally for sites that wish to use this 
> feature).
> 
> (Originally raised here: https://code.djangoproject.com/ticket/29822, posting 
> for discussion)
> 
> -- 
> 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/79896a0e-1338-4267-89bd-9904fca4f0d2%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/AB635EB3-EF1B-4145-B7B6-1BAB347EB0FD%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.