Re: Proposal to re-open #27017 (updating only dirty fields in save())

[Patryk Zawadzki]

I feel conflicted here as I've spent numerous hours under different
contracts fixing bugs caused by missing update_fields and leading to data
loss or inconsistent database states ;)

On a more serious note, please make this happen.

With concurrent updates calling save() without update_fields is asking for
trouble, one of our customers has save() methods specifically patched to
raise exceptions under these circumstances because of how easy it is to
mess things up and how hard it is to track them down.

pon., 28 sty 2019 o 15:00 Daniel Tao  napisał(a):

> Hi!
>
> This is my first post on this list. I recently left a comment on #27017
>  requesting to
> re-open the topic of only saving dirty fields in save(). Tim Graham
> helpfully directed to #4102  and
> advised that I make the proposal on the dev mailing list, so that's what
> I'm doing :)
>
> I've gone through the history of #4102 and taken notes on the challenges
> that arose when this was first attempted 12 years ago (!). The TL;DR is
> that, while there were indeed quite a few complications, I don't see
> anything that came up that should be considered a flat-out showstopper.
> Rather, what happened was that at about the 69th comment
> , back in 2012,
> the conversation shifted as Matt Long made this observation:
>
> what started as a simple opt-in feature request of adding a field
>> white-list to the Model's save function morphed into a complicated dirty
>> flag approach that obviously has many edge cases and performance
>> implications given that this ticket has been open for 5 years now
>
>
> From here it seems things progressed towards the current solution of
> supporting the update_fields argument, and that's where things ended. I
> would like to point out that Matt did *not* advocate for completely
> abandoning all efforts to support dirty field tracking; to the contrary, in
> the same comment he said this (emphasis mine):
>
> Clearly some people feel differently and favor the dirty flag approach for
>> a more hands-off approach. As such, I propose adding support for *both
>> methods*
>
>
> With that in mind, I believe it's worth re-opening this discussion. For a
> fairly lengthy justification, see my aforementioned comment on #27017
> . I'll copy the
> effective TL;DR of the proposal here for convenience:
>
> In my opinion Django could make most code bases inherently more resilient
>> against latent race conditions by implementing some form of dirty field
>> tracking and effectively providing the functionality of update_fields
>> automatically. I would like to propose a new setting, something like
>> SAVE_UPDATE_DIRTY_FIELDS_ONLY, to change the ORM's default behavior so
>> that calls to Model.save() only update the fields that have been set on
>> the model instance. Naturally for backwards compatibility this setting
>> would be False by default.
>
>
> As for the concerns that were raised when this was first attempted, I will
> now attempt to summarize what I found along with, in most cases, a bit of
> editorializing from me.
>
> Performance
>
> The performance angle was first explored in a comment
>  that said it
> "doesn't look good" and provided some benchmarks showing a performance hit
> from 0.17s to 2.64s for setting an attribute using the timeit
>  package. I didn't see
> anyone point out that the timeit method defaults to executing code *a
> million times*; so the throughput of the operation went from about 6
> million to closer to 400 thousand times per second. (The percentage change
> is indeed significant, but this doesn't *smell* like a potential
> bottleneck.)
>
> It was noted in a couple
>  places
>  that it seems
> potentially shortsighted to focus so much on the performance of getting and
> setting attributes without taking into account the potential performance
> *benefits* of executing smaller UPDATE statements that write fewer
> columns. As far as I can tell, no one in the thread on #4102 actively
> investigated the latter.
>
> Based on the unlikelihood of attribute setting representing a performance
> bottleneck, and the lack of data for the performance impact of executing
> smaller updates, I would consider the performance discussion largely a
> distraction. Though I do think it's worth measuring the latter.
>
> Compatibility
>
> It was observed that the two approaches considered on the ticket
> (overriding __setattr__ or defining custom property setters) would not
> work with obj.__dict__.update
> , which is
> apparently an optimization you can find prescri

Re: BitBounce Spam Replies From the Mailing List

[Patryk Zawadzki]

Sorry for resurrecting but this is still very much a problem. Same person, 
same autoresponder.

-- 
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/41722075-8e89-4777-8872-ee4660f14b26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2019

[shrikrishna . s]

Maybe, we could append this idea with the 'Improve less popular database 
backend idea' on the wiki 

 page 
as that project is also not that big for a GSoC project but the purpose of 
both projects seems quite similar to me. So I guess we could have a good 
GSoC project by combining both the idea?

On Friday, January 25, 2019 at 3:04:58 PM UTC+5:30, Florian Apolloner wrote:
>
> On Thursday, January 24, 2019 at 4:01:00 PM UTC+1, Adam Johnson wrote:
>>
>> I'd be happy to help mentor a cross-DB JSONField, it's something I'd like 
>> to see done so I can deprecate the one I maintain in Django-MySQL.
>>
>
> Not sure if GSOC changed that much, but it seems like somewhat small for a 
> GSOC project. 
>

-- 
*
**Crediwatch Information Analytics Private Limited*
*Bangalore Office:* 
#22, 13th Main, Jayanagar 4th Block, Bangalore - 560 011
*Mumbai Office:* 
#1902, 19th Floor, Tower B, Peninsula Business Park G K Marg, Lower Parel, 
Mumbai - 400013
*Confidentiality Notice*: The content of this email is 
confidential  and intended only for the Addressee. All other recipients are 
prohibited from disclosing , copying distributing or taking any action in 
reliance to the contents of this email.

*Please consider the environment 
before printing this e-mail.*

-- 
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/876319c9-2e39-449f-bd2d-2245a98b825a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

['Ivan Anishchuk' via Django developers (Contributions to Django itself)]

Yep, I'm definitely in favor of dropping 3.5 early and using all the nice
features extensively. Especially type annotations. All projects I work on
use 3.6 or later for quite some time now, whatever debian guys might feel
about stability.

Ivan.

On Wed, Jan 23, 2019 at 12:16 PM Josh Smeaton 
wrote:

> Don't discount being able to use features from newer versions of python
> within Django itself.
>
> https://docs.python.org/3/whatsnew/3.6.html
>
> - dicts are more performant
> - dicts/kwargs/class attributes are ordered (cpython implementation detail
> for 3.6 - allowing us to consider removing descriptor counters)
> - fstrings
> - type annotations (something some people are quite in favour of)
> - async comprehensions and generators (less important for Django right now
> - may be more important for Channels)
> - secrets module
> - pathlib
> - descriptor improvements (set_name, __init_subclass__)
>
> I'm more in favour of maintaining the existing policy than playing
> favourites with distro support, but not strongly so. The LTS Django is
> already covering Python 3.5 for 18 months **longer** than the EOL. I don't
> think the newest versions of Django need to be so concerned with distro
> compatibility.
>
> On Wednesday, 23 January 2019 02:03:54 UTC+11, Federico Capoano wrote:
>>
>> I would ask: what are the pros and cons of dropping support for python
>> 3.5?
>>
>> I think allowing users to easily use and install django based
>> applications is more important than strictly follow a python version
>> support policy.
>>
>> I think that if we drop support for python 3.5, which is the default
>> python version on many linux platforms right now, we will make the life of
>> our users and developers harder.
>> I don't understand the reason for doing so, if we have to do it for a
>> good reason, like a security issue, or because django has to take advantage
>> of features that are available only from python 3.6 onwards, I would be in
>> favour, but if we have to do it only because the policy says so, without
>> any other advantage, I would amend the policy.
>>
>> My 2 cents.
>>
>> Thanks for your hard work maintaining django
>> Federico
>>
>>
>> On Monday, January 21, 2019 at 10:56:40 AM UTC-5, Tim Graham wrote:
>>>
>>> When deciding when to drop support for Python 2 in Django, there was
>>> consensus to adopt this Python version support policy [0]: "Typically, we
>>> will support a Python version up to and including the first Django LTS
>>> release whose security support ends after security support for that version
>>> of Python ends. For example, Python 3.3 security support ends September
>>> 2017 and Django 1.8 LTS security support ends April 2018. Therefore Django
>>> 1.8 is the last version to support Python 3.3."
>>>
>>> Since then, we didn't abide by this policy when dropping Python 3.4,
>>> mainly because Debian stable still used Python 3.4 at the time and Claude
>>> argued that some people like him would have difficulty contributing to
>>> Django if they had to install another version of Python [1].
>>>
>>> Based on the policy, it's time to drop support for Python 3.5 in the
>>> master branch (Django 3.0) -- with Django 2.2 LTS supported until April
>>> 2022 and Python 3.5 supported until September 2020). I created a ticket [2]
>>> and PR [3] for dropping support for Python 3.5 [2], however, Claude
>>> commented, "I'm not so enthusiast to drop Python 3.5 now (it is still the
>>> default version in Debian stable). Couldn't this be done in Django 3.1
>>> instead?"
>>>
>>> Are you in favor of amending the Python support version policy to
>>> account for the Python version in Debian stable?
>>>
>>> [0]
>>> https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-can-i-use-with-django
>>> [1]
>>> https://groups.google.com/d/msg/django-developers/4rbVKJYm8DI/TTh3i04pBQAJ
>>> [2] https://code.djangoproject.com/ticket/30116
>>> [3] https://github.com/django/django/pull/10864
>>>
>> --
> 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/a8e5bc63-15b1-4c77-92ae-59e61daa30fd%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+un

Re: Proposal to re-open #27017 (updating only dirty fields in save())

['Ivan Anishchuk' via Django developers (Contributions to Django itself)]

While I'm not sure I have any particular suggestion for this, the problem
is important enough for a few of the projects I'm maintaining. I have
implemented more than a few custom save() methods,
post_init/pre_save/post_save signals and complicated ways of setting
update_fields and acting on their values and I would really like if there
was a simple standard way of tracking dirty fields and saving only them in
a reliable way. I'll be grateful if someone finally makes it happen.

Ivan.

On Tue, Jan 29, 2019 at 4:43 PM Patryk Zawadzki  wrote:

> I feel conflicted here as I've spent numerous hours under different
> contracts fixing bugs caused by missing update_fields and leading to data
> loss or inconsistent database states ;)
>
> On a more serious note, please make this happen.
>
> With concurrent updates calling save() without update_fields is asking for
> trouble, one of our customers has save() methods specifically patched to
> raise exceptions under these circumstances because of how easy it is to
> mess things up and how hard it is to track them down.
>
> pon., 28 sty 2019 o 15:00 Daniel Tao  napisał(a):
>
>> Hi!
>>
>> This is my first post on this list. I recently left a comment on #27017
>>  requesting to
>> re-open the topic of only saving dirty fields in save(). Tim Graham
>> helpfully directed to #4102  and
>> advised that I make the proposal on the dev mailing list, so that's what
>> I'm doing :)
>>
>> I've gone through the history of #4102 and taken notes on the challenges
>> that arose when this was first attempted 12 years ago (!). The TL;DR is
>> that, while there were indeed quite a few complications, I don't see
>> anything that came up that should be considered a flat-out showstopper.
>> Rather, what happened was that at about the 69th comment
>> , back in 2012,
>> the conversation shifted as Matt Long made this observation:
>>
>> what started as a simple opt-in feature request of adding a field
>>> white-list to the Model's save function morphed into a complicated dirty
>>> flag approach that obviously has many edge cases and performance
>>> implications given that this ticket has been open for 5 years now
>>
>>
>> From here it seems things progressed towards the current solution of
>> supporting the update_fields argument, and that's where things ended. I
>> would like to point out that Matt did *not* advocate for completely
>> abandoning all efforts to support dirty field tracking; to the contrary, in
>> the same comment he said this (emphasis mine):
>>
>> Clearly some people feel differently and favor the dirty flag approach
>>> for a more hands-off approach. As such, I propose adding support for *both
>>> methods*
>>
>>
>> With that in mind, I believe it's worth re-opening this discussion. For a
>> fairly lengthy justification, see my aforementioned comment on #27017
>> . I'll copy the
>> effective TL;DR of the proposal here for convenience:
>>
>> In my opinion Django could make most code bases inherently more resilient
>>> against latent race conditions by implementing some form of dirty field
>>> tracking and effectively providing the functionality of update_fields
>>> automatically. I would like to propose a new setting, something like
>>> SAVE_UPDATE_DIRTY_FIELDS_ONLY, to change the ORM's default behavior so
>>> that calls to Model.save() only update the fields that have been set on
>>> the model instance. Naturally for backwards compatibility this setting
>>> would be False by default.
>>
>>
>> As for the concerns that were raised when this was first attempted, I
>> will now attempt to summarize what I found along with, in most cases, a bit
>> of editorializing from me.
>>
>> Performance
>>
>> The performance angle was first explored in a comment
>>  that said it
>> "doesn't look good" and provided some benchmarks showing a performance hit
>> from 0.17s to 2.64s for setting an attribute using the timeit
>>  package. I didn't see
>> anyone point out that the timeit method defaults to executing code *a
>> million times*; so the throughput of the operation went from about 6
>> million to closer to 400 thousand times per second. (The percentage change
>> is indeed significant, but this doesn't *smell* like a potential
>> bottleneck.)
>>
>> It was noted in a couple
>>  places
>>  that it seems
>> potentially shortsighted to focus so much on the performance of getting and
>> setting attributes without taking into account the potential performance
>> *benefits* of executing smaller UPDATE statements that write fewer
>> columns. As far as I can tell, no one in the thread on #

Re: Google Summer of Code 2019

[shrikrishna singh]

Hello Carlton,

I am interested to do a GSoC project based on this idea and looking forward 
to researching on this topic and drafting a proposal.

In the mean, can you please suggest me any easy picking ticket(related to 
this idea) I should work on?

Thanks,
Shrikrishna

-- 
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/bb02e566-a5bd-4c6e-a5e9-2c38913414d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

database configuration error(django and mysql)

[Desh Deepak]

Forbidden (403)

CSRF verification failed. Request aborted.
Help

Reason given for failure:

CSRF token missing or incorrect.


In general, this can occur when there is a genuine Cross Site Request
Forgery, or when Django's CSRF mechanism
 has not been used
correctly. For POST forms, you need to ensure:

   - Your browser is accepting cookies.
   - The view function passes a request to the template's render
   

method.
   - In the template, there is a {% csrf_token %} template tag inside each
   POST form that targets an internal URL.
   - If you are not using CsrfViewMiddleware, then you must use csrf_protect on
   any views that use the csrf_token template tag, as well as those that
   accept the POST data.
   - The form has a valid CSRF token. After logging in in another browser
   tab or hitting the back button after a login, you may need to reload the
   page with the form, because the token is rotated after a login.

You're seeing the help section of this page because you have DEBUG = True in
your Django settings file. Change that to False, and only the initial error
message will be displayed.

You can customize this page using the CSRF_FAILURE_VIEW setting.

-- 
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/CAJ0m4xj66-WXGviUkYhtJWgL--NCQ-QpDQEAULaVDYrzsYfaYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: database configuration error(django and mysql)

[Nick Perry (Souldeux)]

Desh, as Adam already mentioned to you once before:

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



___
Nick Perry
404.660.1020
nperr...@gmail.com



> On Jan 29, 2019, at 10:13 AM, Desh Deepak  wrote:
> 
> 
> Forbidden (403)
> CSRF verification failed. Request aborted.
> Help
> Reason given for failure:
> CSRF token missing or incorrect.
> 
> In general, this can occur when there is a genuine Cross Site Request 
> Forgery, or when Django's CSRF mechanism 
>  has not been used 
> correctly. For POST forms, you need to ensure:
> Your browser is accepting cookies.
> The view function passes a request to the template's render 
> 
>  method.
> In the template, there is a {% csrf_token %} template tag inside each POST 
> form that targets an internal URL.
> If you are not using CsrfViewMiddleware, then you must use csrf_protect on 
> any views that use the csrf_token template tag, as well as those that accept 
> the POST data.
> The form has a valid CSRF token. After logging in in another browser tab or 
> hitting the back button after a login, you may need to reload the page with 
> the form, because the token is rotated after a login.
> You're seeing the help section of this page because you have DEBUG = True in 
> your Django settings file. Change that to False, and only the initial error 
> message will be displayed.
> You can customize this page using the CSRF_FAILURE_VIEW setting.
> 
> -- 
> 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/CAJ0m4xj66-WXGviUkYhtJWgL--NCQ-QpDQEAULaVDYrzsYfaYQ%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/721980F8-DE24-4057-AB3A-F15D25815B78%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2019

[Carlton Gibson]

Hi Shrikrishna, 

Not so much a ticket… See the thread I linked. There’s a lot of info there. 

The first step (I think) is a proof-of-concept JSONField for SQLite — we have 
the other three DBs. 

So taking a look at the implementation of the existing fields and SQLite’s API 
for the JSON extension, should lead you to be able to put together the first 
draft of some thoughts as to how we’d go forward. 

Have a rummage in `contrib.postgres` (and the Oracle and MySQL examples). How 
do the equivalent lookups look in SQLite? (HasKey, ContainedBy, and so on.) Any 
blockers? 

A rough breakdown here would be a good starting point. 

>From there, there are lots of people here who know a lot about this stuff 
>(more that me). 

I’m wondering about Florian’s point about scope. I don’t know much about GSoC, 
so I don’t know what they’d require. 
(The other wish-list item for me is a cross-DB ArrayField, but I haven’t even 
begun to look what the support is like there, if any at all.) 

Kind Regards,

Carlton

-- 
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/ADB006C1-4936-4949-83EC-4138176A27D0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2019

[Adam Johnson]

Small point: a cross-DB JSONField could also serve as a cross-DB
ArrayField, since JSON can store arrays. I don't believe MySQL or SQLite
have "array" types, so to build a cross-DB ArrayField you'd emulate them
with JSON plus a restriction to just storing arrays, which comes back to
building a cross-DB JSONField.

On Tue, 29 Jan 2019 at 17:51, Carlton Gibson 
wrote:

> Hi Shrikrishna,
>
> Not so much a ticket… See the thread I linked. There’s a lot of info
> there.
>
> The first step (I think) is a proof-of-concept JSONField for SQLite — we
> have the other three DBs.
>
> So taking a look at the implementation of the existing fields and SQLite’s
> API for the JSON extension, should lead you to be able to put together the
> first draft of some thoughts as to how we’d go forward.
>
> Have a rummage in `contrib.postgres` (and the Oracle and MySQL examples).
> How do the equivalent lookups look in SQLite? (HasKey, ContainedBy, and so
> on.) Any blockers?
>
> A rough breakdown here would be a good starting point.
>
> From there, there are lots of people here who know a lot about this stuff
> (more that me).
>
> I’m wondering about Florian’s point about scope. I don’t know much about
> GSoC, so I don’t know what they’d require.
> (The other wish-list item for me is a cross-DB ArrayField, but I haven’t
> even begun to look what the support is like there, if any at all.)
>
> Kind Regards,
>
> Carlton
>
> --
> 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/ADB006C1-4936-4949-83EC-4138176A27D0%40gmail.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/CAMyDDM3jD7Zsr2io8hv2AMez0QxNZcbEscfpCirH2o3K5vCxRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

data sharing with multiple clients by server simultaneously

[shiva kumar]

Hi guys. I have a doubt regrading communication b\w client and server.
consider an example there are 20 clients continuously connected and share
data with server and server response to there request.
my requirements are
 What are all the concepts needed inorder to make it? and some alternatives.

thank u

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

Re: Google Summer of Code 2019

[shrikrishna singh]

Thanks for the input Carlton and Adam. I will start working on the POC then.

On Tuesday, January 29, 2019 at 11:41:48 PM UTC+5:30, Adam Johnson wrote:
>
> Small point: a cross-DB JSONField could also serve as a cross-DB 
> ArrayField, since JSON can store arrays. I don't believe MySQL or SQLite 
> have "array" types, so to build a cross-DB ArrayField you'd emulate them 
> with JSON plus a restriction to just storing arrays, which comes back to 
> building a cross-DB JSONField.
>
> On Tue, 29 Jan 2019 at 17:51, Carlton Gibson  > wrote:
>
>> Hi Shrikrishna, 
>>
>> Not so much a ticket… See the thread I linked. There’s a lot of info 
>> there. 
>>
>> The first step (I think) is a proof-of-concept JSONField for SQLite — we 
>> have the other three DBs. 
>>
>> So taking a look at the implementation of the existing fields and 
>> SQLite’s API for the JSON extension, should lead you to be able to put 
>> together the first draft of some thoughts as to how we’d go forward. 
>>
>> Have a rummage in `contrib.postgres` (and the Oracle and MySQL examples). 
>> How do the equivalent lookups look in SQLite? (HasKey, ContainedBy, and so 
>> on.) Any blockers? 
>>
>> A rough breakdown here would be a good starting point. 
>>
>> From there, there are lots of people here who know a lot about this stuff 
>> (more that me). 
>>
>> I’m wondering about Florian’s point about scope. I don’t know much about 
>> GSoC, so I don’t know what they’d require. 
>> (The other wish-list item for me is a cross-DB ArrayField, but I haven’t 
>> even begun to look what the support is like there, if any at all.) 
>>
>> Kind Regards,
>>
>> Carlton
>>
>> -- 
>> 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/ADB006C1-4936-4949-83EC-4138176A27D0%40gmail.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/c8a97dda-deeb-4050-a334-60b605d24ea6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: data sharing with multiple clients by server simultaneously

[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, 29 Jan 2019 at 17:51, shiva kumar 
wrote:

> Hi guys. I have a doubt regrading communication b\w client and server.
> consider an example there are 20 clients continuously connected and share
> data with server and server response to there request.
> my requirements are
>  What are all the concepts needed inorder to make it? and some
> alternatives.
>
> thank u
>
> --
> 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/CAMsYeuHUAtE0TaoOpbLrha%3DQ8NsOqrsji65eu04Md6QS8bHQfA%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/CAMyDDM3UgE3FqDsBZRrcqAe_T%3Dj17cCVMf7A_M5pAaPhQtByNg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.