Re: Proposal: Refactor Form class

[Curtis Maloney]

Hi,

On 04/03/16 07:00, 'Moritz Sichert' via Django developers 
(Contributions to Django itself) wrote:

Hello,

I want to propose a refactor of the Form class to make it
easier to customize and subclass.


I've recently had thoughts in this direction, so seeing your post 
intrigued me...


However, I feel some of your assertions are a bit off the mark...


Motivation:

Currently the Form class (combined with Field, Widget and
BoundField) has many responsibilities and combines much
functionality into a single class. It currently does:

- data validation (using Field validators and clean*
   methods)


Correct - this is the main purpose of Forms.


- parsing HTTP form data and handling special cases like
   file upload (using Widget.value_from_datadict() and
   Field.to_python())


Well, Widgets and Fields are involved in determining how to extract data 
from the submitted dict... but they don't actually "parse" the http form 
data -- Django does that much further down the stack in the HttpRequest 
object.




- displaying values as HTML input fields (using
   Widget.render(), BoundField.value(), Field.prepare_value()
   and even the Media class)




Although those three functionalities are closely related one
can easily think of situations where only one is needed.
Following Django's principle of loose coupling it would also
be desirable to be able to exchange components.



For example, it's conceivable that the form data doesn't
come from a HTTP request with x-www-form-urlencoded or
multipart/form-data content but gets transferred as JSON. In
this case it should be easy to replace the HTTP parsing


As mentioned above, Forms don't handle this parsing.  You can pass _any_ 
dict-like for them to validate.  In fact, I (and many others) have used 
this for a simple and effective way to import csv files, in combination 
with stdlib's csv.DictReader.


I also frequently use Forms for validating JSON data...


Also HTML forms may not be the only place where data
validation is needed. An application may get an untrusted
dict of Python objects that doesn't have to be parsed but
should still be validated. In that case it would be nice to
be able to just use the data validation component.



Therefore I propose splitting the Form class into multiple
components that can be easily exchanged and used without
another.


Here we somewhat agree.

My view was Forms involve the following actions:

1. Validation - the most important.
2. Rendering - currently handled by widgets
3. Sourcing - pulling in data, initial, defaults [POST, Form initial, 
ModelForm instance, etc]

4. Sinking - pushing out validated data [cleaned_data, ModelForm.save()]

I feel the current validation pattern is very powerful and flexible, and 
don't see much need to alter it.


In prior discussions about improving rendering in forms [a long time 
bugbear of mine] there are a number of subtleties that are not so 
obvious at first blush, where the current implementation blurs the Field 
and Widget.


ModelForm's show a reasonable example for how to overlay extensions for 
sourcing and sinking, but a more formalised approach could certainly 
benefit the wider range of practices in the modern web.



Rationale:

To give you a better idea about the proposal I already
prepared a general architecture of how I think this could be
implemented. This is of course in no way final and I'll be
happy to receive feedback and suggestions!

Components:

Each of the aforementioned components is implemented in a
class of its own:

- FormValidator:
   Implements the data validation as the name suggests. It
   uses Field instances that can be declared declaratively as
   it is possible with the old Form class. Furthermore it
   provides all methods of the old Form class that dealt with
   data validation, i.e. clean*(), is_valid(), errors(), etc.


Agreed.


- DataProvider:
   Implements the "parsing and providing data" component. It
   has only one method "get_value(name)" that must be
   overwritten by subclasses and returns the data for a given
   field name.


So that would be a "get_field_value"?


   HtmlFormProvider is a subclass of DataProvider that
   provides the parsing of HTTP form content by using Widget
   objects and their "value_from_datadict()" method in
   particular. The widgets of a HtmlFormProvider can be
   specified declaratively just like the fields of a
   FormValidator.



- HtmlForm:
   Implements the "displaying values as HTML input fields"
   component. Same as HtmlFormProvider it uses Widget objects
   and their "render()" method in particular. It also
   features all methods of the old Form class that were used
   mainly in templates, like __iter__(), __getitem__(),
   __str__(), as_p(), etc.



   Furthermore it fetches its data from a given
   HtmlFormProvider instance and provides handling of error
   messages with a FormValidator instance. It is also
   possible to decouple HtmlForm and HtmlFormProvider such
   that HtmlForm works with 

Re: Proposal: Refactor Form class

[is_null]

Hi

On Thursday, March 3, 2016 at 9:00:47 PM UTC+1, Moritz S. wrote:
>
> For example, it's conceivable that the form data doesn't 
> come from a HTTP request with x-www-form-urlencoded or 
> multipart/form-data content but gets transferred as JSON. In 
> this case it should be easy to replace the HTTP parsing 
> component with a JSON parser. 
>

That's the case when using ReactNative for example. 

However, it is easy to make the client do a standard HTTP post request.
 

> Also HTML forms may not be the only place where data 
> validation is needed. An application may get an untrusted 
> dict of Python objects that doesn't have to be parsed but 
> should still be validated. In that case it would be nice to 
> be able to just use the data validation component. 
>

I'd like to see where that goes, it does sound pretty useful to me.

When users do validation without the framework it's not unusual to find 
security bugs :)

Perhaps you'd have more luck if you'd split your proposal and make a 
smaller proposal, wait and see ...

-- 
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/95f4e9dc-3bae-4af4-bdf5-7f26d7b0deef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Loïc Bistuer]

I’m not too keen on a contrib.pg field. CharField is the base class of many 
fields, a __init__ kwarg approach such as max_length=None allows us to reach 
those as well.

> On Mar 5, 2016, at 3:05 AM, Marc Tamlyn  wrote:
> 
> Voting:
> 
> 1) should there be a default?
> 
> I'm lazy, so I would be happy to have one. Where validation matters you can 
> change it, where it doesn't you don't have to. I'd draw an analogy to 
> (Positive)(Small)IntegerField - I often use the normal one when I mean some 
> variant of validation, or some other max/min value.
> 
> 2) how to make it easy to have no limit on PG?
> 
> If it's truly pg specific, then a contrib.pg field seems fine, though 
> probably call it UnlimitedCharField for lack of ambiguity.
> 
> M
> 
> On 1 Mar 2016 1:11 a.m., "Markus Holtermann"  wrote:
> From what I understand you will have a hard time doing that at all:
> 
> On PG could go with a 'max_length=None' in a 3rd party app. But that wouldn't 
> be supported on any other database backend. Which means you're limiting your 
> app to PG. On the other hand you could make your app database independent by 
> using a TextField which has pretty much the same performance on PG as a 
> VARCHAR() and is available on other backends. But may perform bad on other 
> backends. But there's no way to have a text of unlimited length on MySQL 
> other than a TEXT column.
> 
> TL;DR: you can't achieve both ways anyway. Neither now nor if we change the 
> behavior of Django's max_length attribute on CharFields.
> 
> /Markus
> 
> On Tuesday, March 1, 2016 at 11:00:29 AM UTC+11, Cristiano Coelho wrote:
> I find that using TextField rather than CharField just to make postgres use 
> varchar() is a terrible idea, if you are implementing an reusable app and it 
> is used on a backend like MySQL where TextFields are created as text columns 
> which are horribly inneficient and should be avoided at any cost you will 
> have a really bad time.
> I'm not sure about postgres but I want to believe that using varchar without 
> limits has also some performance considerations that should be taken care of.
> 
> El lunes, 29 de febrero de 2016, 17:58:33 (UTC-3), Shai Berger escribió:
> Hi, 
> 
> Thank you, Aymeric, for summing up the discussion this way. The division into 
> two separate problems is indeed required, and I fully support the idea of 
> setting max_length's default to 100 or 120. 
> 
> There seem to be just two points worth adding to your summary: 
> 
> On Monday 29 February 2016 11:19:02 Aymeric Augustin wrote: 
> > 
> > 2) How can we make it easy for PostgreSQL users to just use VARCHAR()? 
> > 
> > Since this is a PostgreSQL-specific feature, having a variant of CharField 
> > in django.contrib.postgres that supports and perhaps even defaults to 
> > unlimited length shouldn’t be controversial. 
> > 
> 
> The first -- I believe it was raised very early on by Christophe Pettus -- is 
> that Django already has a field that manifests on PG as VARCHAR(), and that 
> is 
> TextField. However, I don't like the idea that PG users should be using 
> TextField(widget=TextInput) as a replacement for CharField; I find that 
> counter-intuitive -- even if just because it is a "bad name". Names are 
> important. 
> 
> The second -- in response to a comment made by Josh Smeaton -- is that having 
> django.db.models.CharField with default max_lenth=N (for some finite N) and 
> django.contrib.postgres.CharField with default max_length=None (meaning 
> infinity) sounds like a bad idea. 
> 
> > 
> > I hope this helps! 
> 
> I'm certain it did! 
> 
> 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 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/71e5e743-29bb-4dba-9bf4-6948ab2d1fa9%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/CAMwjO1Gj3E4_83qdbQmQwXe_WdTXUf7yuZ44-aQ9jgvJN9-5sg%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 develop

Django Integration

[Chad Paulson]

I was happy to read that part of the Mozilla Open Source Support program 
funding that was recently awarded to the Django Software Foundation will go 
toward integrating key components of Django REST Framework into Django.

Since I haven't found any update since the initial announcement in 
December, I was curious what the status of this integration is and, if 
possible, how soon it might be available.

https://www.djangoproject.com/weblog/2015/dec/11/django-awarded-moss-grant/

-- 
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/2bdf074c-5e21-48cf-a93c-ba19f7744a89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Adding "bits of entropy" argument to crypto.get_random_string

[Nick Timkovich]

Rather than guess at the appropriate string length to get some level of 
security, I'd like to add a (minimum) bits of entropy argument to 
get_random_string, so I could say something like get_random_string(bits=256) 
and have it do the math for me: math.ceil(bits / 
math.log2(len(allowed_chars))).

Not sure what should happen if both bits and length are specified, let bits 
override? ValueError? whichever is longer/more random/secure (maybe then 
call it min_bits)?

I seem to recycle that snippet in many of my projects, and I hope it would 
be useful for others. 

-- 
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/bc93fd3e-4e8c-45e6-9ada-4fa595bf4479%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: TransactionManagementError is raised when autocommit …

[Tore Lundqvist]

I don't what all updates to be in one commit each so I can't wrap just the 
update with a atomic block I would need to have it over a bigger chuck of 
code. That chunk might call a subrutin that also needs a commit and if I 
wrap that update in a atomic block that atomic block is nested and results 
in a save point which is useless.

Den fredag 4 mars 2016 kl. 22:46:30 UTC+1 skrev Aymeric Augustin:
>
> If you do what Simon and I suggest, you should get the result you just 
> described. If you don’t, please explain what happens.
>
> Within a transaction — and disabling autocommit means you’re within a 
> transaction — transaction.atomic() uses savepoints.
>
> Note that in Django 1.6, after set_autocommit(False), you couldn’t use 
> transaction.atomic(). That was fixed in 1.8 (I think).
>
> -- 
> Aymeric.
>
> On 04 Mar 2016, at 21:21, Tore Lundqvist > 
> wrote:
>
> Hi, Simon
>
> No, I would need to wrap everything i a atomic block to start the 
> transaction and it's only when that outermost atomic block exits that I 
> actually get a commit the nested ones just makes save point.
>
> /Tore 
>
> Den fredag 4 mars 2016 kl. 21:09:17 UTC+1 skrev charettes:
>>
>> Hi Tore,
>>
>> Is there a reason you can't simply wrap your updates in a 
>> `transaction.atomic()` blocks?
>>
>> You should be able to avoid deadlocks and control exactly when data is 
>> written to disk
>> with this construct.
>>
>> Simon
>>
>> Le vendredi 4 mars 2016 15:02:45 UTC-5, Tore Lundqvist a écrit :
>>>
>>> Reply to comments in ticket: 
>>> https://code.djangoproject.com/ticket/26323#comment:10
>>>
>>> Hi, 
>>>
>>> @Aagustin: I get your point but in the code I'm working on there is a 
>>> lot of transaction.commit(), not to handle transactions but to manage when 
>>> data is written to disk and to avoid deadlocks. Running in autocommit mode 
>>> does not work, its slow and sometimes the commits is used to save in a 
>>> known good state. So I disable autocommit with 
>>> transaction.set_autocommit(False) and run the code with explicit commits in 
>>> it and than turn autocommit on again. 
>>>
>>> The documentation for set_autocommit says "Once you turn autocommit off, 
>>> you get the default behavior of your database adapter, and Django won’t 
>>> help you." That is what I want and thats way I think that 
>>> the TransactionManagementError should not de raise if your not using atomic 
>>> blocks. 
>>>
>>
> -- 
> 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-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/a6077f33-1113-4767-828c-8b2c0c77bd78%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/79611d30-21e0-45bc-8ab7-8754a39db4fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Question] jsi18n - get_javascript_catalog a bit obscure?

[Tim Graham]

Please read https://code.djangoproject.com/

On Friday, March 4, 2016 at 4:47:39 PM UTC-5, Cristiano Coelho wrote:
>
> Where do I get an account for Trac tickets? :) I guess I should still open 
> a ticket first
>
> El viernes, 4 de marzo de 2016, 18:31:41 (UTC-3), Tim Graham escribió:
>>
>> Sure, I mean... my impression as indicated by the lack of response to the 
>> thread is that no one provides much expertise in javascript_catalog() these 
>> days (although it's only been a couple days). I don't use it myself so I do 
>> my best to review proposed changes and then we wait for bug reports. Maybe 
>> this will be the start of your journey to being that expert.
>>
>> Quoting https://github.com/django/django/blob/master/CONTRIBUTING.rst, 
>> "non-trivial pull requests (anything more than fixing a typo) without Trac 
>> tickets will be closed! Please file a ticket 
>>  to suggest changes."
>>
>> On Friday, March 4, 2016 at 4:11:08 PM UTC-5, Cristiano Coelho wrote:
>>>
>>> Would a pull request be accepted? Does it need to be a new branch even 
>>> if the change is just a few lines? Does it need an open ticket first?
>>>
>>> El martes, 1 de marzo de 2016, 22:26:00 (UTC-3), Cristiano Coelho 
>>> escribió:

 Looking through git history seems like the "always load english 
 translations" code is quite a few years old.

 There's a 5 y.o ticket in here: 
 https://code.djangoproject.com/ticket/16284

 Which leads to here: https://code.djangoproject.com/ticket/3594 with a 
 fix that adds the "discard if english not found" which doesn't resolve the 
 issue completely if you actually have english translations but it is not 
 the default language.

 There's also a link to here: 
 https://groups.google.com/forum/#!topic/django-developers/1X_tPbhG_NQ 
 proposing a change with no replies at all.

 I couldn't really understand why is it that the hardcoded english 
 language can not be removed from here.

 In my opinion the code should be slightly changed to only load the 
 default language rather than english (and as long as the requested 
 language 
 is not the same as the default one) as fallback, so it can match the 
 actual 
 server side behaviour, which will load the configured language (at 
 settings) as a fallback language as long as it is different from it (an 
 from english, which makes sense because django text ids are all in 
 english).
 This change could however affect people that relies on always having an 
 english translation as fallback when the configured default language is 
 not 
 english (does this even make sense? Would anyone do that?)

 After this change is done, there could be an improvement (for both js 
 and server side translations) that some people might find useful, rather 
 than always falling back to the default configured language, you could 
 have 
 a map of fallbacks, for example, if the user requests a portuguese 
 language, but you only have english (default) and spanish (secondary), it 
 makes more sense to fallback to spanish rather than english, but if the 
 user requests russian, it makes more sense to fallback to english.

 El martes, 1 de marzo de 2016, 21:29:42 (UTC-3), Tim Graham escribió:
>
> Have you tried looking through history with git blame to find related 
> tickets? Another tip is to search Google with a query like 
> "javascript_catalog site:code.djangoproject.com". This will let you 
> find tickets to see if the issue was raised before. This is how I try to 
> answer questions like this since many of the original authors are no 
> longer 
> active (or at least, you can find the person who authored the code in 
> question and try a more directed query like a ping in IRC).
>
> On Tuesday, March 1, 2016 at 6:23:38 PM UTC-5, Cristiano Coelho wrote:
>>
>> Maybe I wasn't clear neither, but the main issue is this: when using 
>> a language equals to the default one, and if that language does not 
>> define 
>> any translation text (because ids are the same as values so it is not 
>> necessary), the server side translations will always correctly return 
>> the 
>> translated texts, while the javascript won't because it always has an 
>> english fallback.
>> Also the code I provided should actually load the default language 
>> translations as well (but not the english ones!) to make it behave 
>> exactly 
>> as the server side translations.
>>
>

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

Re: [Question] jsi18n - get_javascript_catalog a bit obscure?

[Cristiano Coelho]

Where do I get an account for Trac tickets? :) I guess I should still open 
a ticket first

El viernes, 4 de marzo de 2016, 18:31:41 (UTC-3), Tim Graham escribió:
>
> Sure, I mean... my impression as indicated by the lack of response to the 
> thread is that no one provides much expertise in javascript_catalog() these 
> days (although it's only been a couple days). I don't use it myself so I do 
> my best to review proposed changes and then we wait for bug reports. Maybe 
> this will be the start of your journey to being that expert.
>
> Quoting https://github.com/django/django/blob/master/CONTRIBUTING.rst, 
> "non-trivial pull requests (anything more than fixing a typo) without Trac 
> tickets will be closed! Please file a ticket 
>  to suggest changes."
>
> On Friday, March 4, 2016 at 4:11:08 PM UTC-5, Cristiano Coelho wrote:
>>
>> Would a pull request be accepted? Does it need to be a new branch even if 
>> the change is just a few lines? Does it need an open ticket first?
>>
>> El martes, 1 de marzo de 2016, 22:26:00 (UTC-3), Cristiano Coelho 
>> escribió:
>>>
>>> Looking through git history seems like the "always load english 
>>> translations" code is quite a few years old.
>>>
>>> There's a 5 y.o ticket in here: 
>>> https://code.djangoproject.com/ticket/16284
>>>
>>> Which leads to here: https://code.djangoproject.com/ticket/3594 with a 
>>> fix that adds the "discard if english not found" which doesn't resolve the 
>>> issue completely if you actually have english translations but it is not 
>>> the default language.
>>>
>>> There's also a link to here: 
>>> https://groups.google.com/forum/#!topic/django-developers/1X_tPbhG_NQ 
>>> proposing a change with no replies at all.
>>>
>>> I couldn't really understand why is it that the hardcoded english 
>>> language can not be removed from here.
>>>
>>> In my opinion the code should be slightly changed to only load the 
>>> default language rather than english (and as long as the requested language 
>>> is not the same as the default one) as fallback, so it can match the actual 
>>> server side behaviour, which will load the configured language (at 
>>> settings) as a fallback language as long as it is different from it (an 
>>> from english, which makes sense because django text ids are all in english).
>>> This change could however affect people that relies on always having an 
>>> english translation as fallback when the configured default language is not 
>>> english (does this even make sense? Would anyone do that?)
>>>
>>> After this change is done, there could be an improvement (for both js 
>>> and server side translations) that some people might find useful, rather 
>>> than always falling back to the default configured language, you could have 
>>> a map of fallbacks, for example, if the user requests a portuguese 
>>> language, but you only have english (default) and spanish (secondary), it 
>>> makes more sense to fallback to spanish rather than english, but if the 
>>> user requests russian, it makes more sense to fallback to english.
>>>
>>> El martes, 1 de marzo de 2016, 21:29:42 (UTC-3), Tim Graham escribió:

 Have you tried looking through history with git blame to find related 
 tickets? Another tip is to search Google with a query like 
 "javascript_catalog site:code.djangoproject.com". This will let you 
 find tickets to see if the issue was raised before. This is how I try to 
 answer questions like this since many of the original authors are no 
 longer 
 active (or at least, you can find the person who authored the code in 
 question and try a more directed query like a ping in IRC).

 On Tuesday, March 1, 2016 at 6:23:38 PM UTC-5, Cristiano Coelho wrote:
>
> Maybe I wasn't clear neither, but the main issue is this: when using a 
> language equals to the default one, and if that language does not define 
> any translation text (because ids are the same as values so it is not 
> necessary), the server side translations will always correctly return the 
> translated texts, while the javascript won't because it always has an 
> english fallback.
> Also the code I provided should actually load the default language 
> translations as well (but not the english ones!) to make it behave 
> exactly 
> as the server side translations.
>


-- 
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/b7b77cd7-8f0e-4d88-b425-875792db20ad%40googlegroups.com.
For more 

Re: TransactionManagementError is raised when autocommit …

[Aymeric Augustin]

If you do what Simon and I suggest, you should get the result you just 
described. If you don’t, please explain what happens.

Within a transaction — and disabling autocommit means you’re within a 
transaction — transaction.atomic() uses savepoints.

Note that in Django 1.6, after set_autocommit(False), you couldn’t use 
transaction.atomic(). That was fixed in 1.8 (I think).

-- 
Aymeric.

> On 04 Mar 2016, at 21:21, Tore Lundqvist  wrote:
> 
> Hi, Simon
> 
> No, I would need to wrap everything i a atomic block to start the transaction 
> and it's only when that outermost atomic block exits that I actually get a 
> commit the nested ones just makes save point.
> 
> /Tore 
> 
> Den fredag 4 mars 2016 kl. 21:09:17 UTC+1 skrev charettes:
> Hi Tore,
> 
> Is there a reason you can't simply wrap your updates in a 
> `transaction.atomic()` blocks?
> 
> You should be able to avoid deadlocks and control exactly when data is 
> written to disk
> with this construct.
> 
> Simon
> 
> Le vendredi 4 mars 2016 15:02:45 UTC-5, Tore Lundqvist a écrit :
> Reply to comments in ticket: 
> https://code.djangoproject.com/ticket/26323#comment:10 
> 
> 
> Hi, 
> 
> @Aagustin: I get your point but in the code I'm working on there is a lot of 
> transaction.commit(), not to handle transactions but to manage when data is 
> written to disk and to avoid deadlocks. Running in autocommit mode does not 
> work, its slow and sometimes the commits is used to save in a known good 
> state. So I disable autocommit with transaction.set_autocommit(False) and run 
> the code with explicit commits in it and than turn autocommit on again. 
> 
> The documentation for set_autocommit says "Once you turn autocommit off, you 
> get the default behavior of your database adapter, and Django won’t help 
> you." That is what I want and thats way I think that the 
> TransactionManagementError should not de raise if your not using atomic 
> blocks. 
> 
> -- 
> 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/a6077f33-1113-4767-828c-8b2c0c77bd78%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/838C906E-6290-4C70-9E4C-8E6E7832CCF1%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: [Question] jsi18n - get_javascript_catalog a bit obscure?

[Tim Graham]

Sure, I mean... my impression as indicated by the lack of response to the 
thread is that no one provides much expertise in javascript_catalog() these 
days (although it's only been a couple days). I don't use it myself so I do 
my best to review proposed changes and then we wait for bug reports. Maybe 
this will be the start of your journey to being that expert.

Quoting https://github.com/django/django/blob/master/CONTRIBUTING.rst, 
"non-trivial pull requests (anything more than fixing a typo) without Trac 
tickets will be closed! Please file a ticket 
 to suggest changes."

On Friday, March 4, 2016 at 4:11:08 PM UTC-5, Cristiano Coelho wrote:
>
> Would a pull request be accepted? Does it need to be a new branch even if 
> the change is just a few lines? Does it need an open ticket first?
>
> El martes, 1 de marzo de 2016, 22:26:00 (UTC-3), Cristiano Coelho escribió:
>>
>> Looking through git history seems like the "always load english 
>> translations" code is quite a few years old.
>>
>> There's a 5 y.o ticket in here: 
>> https://code.djangoproject.com/ticket/16284
>>
>> Which leads to here: https://code.djangoproject.com/ticket/3594 with a 
>> fix that adds the "discard if english not found" which doesn't resolve the 
>> issue completely if you actually have english translations but it is not 
>> the default language.
>>
>> There's also a link to here: 
>> https://groups.google.com/forum/#!topic/django-developers/1X_tPbhG_NQ 
>> proposing a change with no replies at all.
>>
>> I couldn't really understand why is it that the hardcoded english 
>> language can not be removed from here.
>>
>> In my opinion the code should be slightly changed to only load the 
>> default language rather than english (and as long as the requested language 
>> is not the same as the default one) as fallback, so it can match the actual 
>> server side behaviour, which will load the configured language (at 
>> settings) as a fallback language as long as it is different from it (an 
>> from english, which makes sense because django text ids are all in english).
>> This change could however affect people that relies on always having an 
>> english translation as fallback when the configured default language is not 
>> english (does this even make sense? Would anyone do that?)
>>
>> After this change is done, there could be an improvement (for both js and 
>> server side translations) that some people might find useful, rather than 
>> always falling back to the default configured language, you could have a 
>> map of fallbacks, for example, if the user requests a portuguese language, 
>> but you only have english (default) and spanish (secondary), it makes more 
>> sense to fallback to spanish rather than english, but if the user requests 
>> russian, it makes more sense to fallback to english.
>>
>> El martes, 1 de marzo de 2016, 21:29:42 (UTC-3), Tim Graham escribió:
>>>
>>> Have you tried looking through history with git blame to find related 
>>> tickets? Another tip is to search Google with a query like 
>>> "javascript_catalog site:code.djangoproject.com". This will let you 
>>> find tickets to see if the issue was raised before. This is how I try to 
>>> answer questions like this since many of the original authors are no longer 
>>> active (or at least, you can find the person who authored the code in 
>>> question and try a more directed query like a ping in IRC).
>>>
>>> On Tuesday, March 1, 2016 at 6:23:38 PM UTC-5, Cristiano Coelho wrote:

 Maybe I wasn't clear neither, but the main issue is this: when using a 
 language equals to the default one, and if that language does not define 
 any translation text (because ids are the same as values so it is not 
 necessary), the server side translations will always correctly return the 
 translated texts, while the javascript won't because it always has an 
 english fallback.
 Also the code I provided should actually load the default language 
 translations as well (but not the english ones!) to make it behave exactly 
 as the server side translations.

>>>

-- 
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/0cab22c2-e833-42ff-b387-fb70cbb8f538%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: I don't understand this error - Django 1.9

[Tim Graham]

Try emptying your __init__.py file -- its contents aren't necessary and 
"import apps" may be causing the problem.

In the future, please use django-users for usage/debugging questions like 
this. This mailing list is for discussion about the development of Django 
itself. Thanks!

On Friday, March 4, 2016 at 4:18:34 PM UTC-5, Becka R. wrote:
>
> Hi, 
>
> I'm building a pretty basic CRUD application for a community I'm part of. 
>   I'm now getting "ImportError: No module named [myappname]" when I run the 
> server, and an operational error in the admin. 
>
> I looked at the documentation, and followed the steps, but I'm not doing 
> something correctly.  I'd like to 1) fix this, and 2) propose some changes 
> to the docs to clarify this issue. 
>
> My project is called "ladynerds" (We're a professional association for a 
> bunch of women software engineers). 
>
> Here's the documentation I'm following:
>
> https://docs.djangoproject.com/en/1.9/ref/applications/
>
> I'm using Django 1.9
>
> *Here's my file structure:*
>
> /ladynerds   (project file)
>  /ladynerds  (app)
>   __init__.py
>   models.py
>   forms.py
>   settings.py
>   urls.py
>   views.py
>   wsgi.py
>   /static
>   /templates
>   
>
> *Here's what I put into ladynerds/__init__.py:*
>
>
> import apps
>
> default_app_config = 'LadyNerds.apps.LadyNerdsConfig'
>
>
> I've also tried using 'ladynerds.apps.LadyNerdsConfig'
>
>
> *Here's what I put into ladynerds/apps.py:*
>
> from django.apps import AppConfig
>
> class LadyNerdsConfig(AppConfig):
> name = "LadyNerds"
> verbose_name = "LadyNerds"
>
> *Here's my settings.py INSTALLED_APPS*
>
>
> INSTALLED_APPS = (
> 'ladynerds.apps.LadyNerdsConfig',
> 'django.contrib.admin',
> 'django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.messages',
> 'django.contrib.staticfiles',
> 'ladynerds'
> )
>
>
> I'm getting:  ImportError: No module named LadyNerds
>
> What am I missing?
>
> And, thanks. 
>
> --Becka
>
>

-- 
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/244f6a0d-d148-4e18-a441-d23e9448343f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: I don't understand this error - Django 1.9

[Becka]

Whoops. Wrong list.  Sorry about that.

On Fri, Mar 4, 2016 at 1:18 PM, Becka  wrote:

> Hi,
>
> I'm building a pretty basic CRUD application for a community I'm part of.
>   I'm now getting "ImportError: No module named [myappname]" when I run the
> server, and an operational error in the admin.
>
> I looked at the documentation, and followed the steps, but I'm not doing
> something correctly.  I'd like to 1) fix this, and 2) propose some changes
> to the docs to clarify this issue.
>
> My project is called "ladynerds" (We're a professional association for a
> bunch of women software engineers).
>
> Here's the documentation I'm following:
>
> https://docs.djangoproject.com/en/1.9/ref/applications/
>
> I'm using Django 1.9
>
> *Here's my file structure:*
>
> /ladynerds   (project file)
>  /ladynerds  (app)
>   __init__.py
>   models.py
>   forms.py
>   settings.py
>   urls.py
>   views.py
>   wsgi.py
>   /static
>   /templates
>
>
> *Here's what I put into ladynerds/__init__.py:*
>
>
> import apps
>
> default_app_config = 'LadyNerds.apps.LadyNerdsConfig'
>
>
> I've also tried using 'ladynerds.apps.LadyNerdsConfig'
>
>
> *Here's what I put into ladynerds/apps.py:*
>
> from django.apps import AppConfig
>
> class LadyNerdsConfig(AppConfig):
> name = "LadyNerds"
> verbose_name = "LadyNerds"
>
> *Here's my settings.py INSTALLED_APPS*
>
>
> INSTALLED_APPS = (
> 'ladynerds.apps.LadyNerdsConfig',
> 'django.contrib.admin',
> 'django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.messages',
> 'django.contrib.staticfiles',
> 'ladynerds'
> )
>
>
> I'm getting:  ImportError: No module named LadyNerds
>
> What am I missing?
>
> And, thanks.
>
> --Becka
>
>

-- 
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/CANOxe%2B0F%3D-6PmWD1Xp%2Bnn-nE00j5ZgDV811Lh2MkDRSk%3DgAXWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

I don't understand this error - Django 1.9

[Becka]

Hi,

I'm building a pretty basic CRUD application for a community I'm part of.
I'm now getting "ImportError: No module named [myappname]" when I run the
server, and an operational error in the admin.

I looked at the documentation, and followed the steps, but I'm not doing
something correctly.  I'd like to 1) fix this, and 2) propose some changes
to the docs to clarify this issue.

My project is called "ladynerds" (We're a professional association for a
bunch of women software engineers).

Here's the documentation I'm following:

https://docs.djangoproject.com/en/1.9/ref/applications/

I'm using Django 1.9

*Here's my file structure:*

/ladynerds   (project file)
 /ladynerds  (app)
  __init__.py
  models.py
  forms.py
  settings.py
  urls.py
  views.py
  wsgi.py
  /static
  /templates


*Here's what I put into ladynerds/__init__.py:*


import apps

default_app_config = 'LadyNerds.apps.LadyNerdsConfig'


I've also tried using 'ladynerds.apps.LadyNerdsConfig'


*Here's what I put into ladynerds/apps.py:*

from django.apps import AppConfig

class LadyNerdsConfig(AppConfig):
name = "LadyNerds"
verbose_name = "LadyNerds"

*Here's my settings.py INSTALLED_APPS*


INSTALLED_APPS = (
'ladynerds.apps.LadyNerdsConfig',
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'ladynerds'
)


I'm getting:  ImportError: No module named LadyNerds

What am I missing?

And, thanks.

--Becka

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

Re: [Question] jsi18n - get_javascript_catalog a bit obscure?

[Cristiano Coelho]

Would a pull request be accepted? Does it need to be a new branch even if 
the change is just a few lines? Does it need an open ticket first?

El martes, 1 de marzo de 2016, 22:26:00 (UTC-3), Cristiano Coelho escribió:
>
> Looking through git history seems like the "always load english 
> translations" code is quite a few years old.
>
> There's a 5 y.o ticket in here: 
> https://code.djangoproject.com/ticket/16284
>
> Which leads to here: https://code.djangoproject.com/ticket/3594 with a 
> fix that adds the "discard if english not found" which doesn't resolve the 
> issue completely if you actually have english translations but it is not 
> the default language.
>
> There's also a link to here: 
> https://groups.google.com/forum/#!topic/django-developers/1X_tPbhG_NQ 
> proposing a change with no replies at all.
>
> I couldn't really understand why is it that the hardcoded english language 
> can not be removed from here.
>
> In my opinion the code should be slightly changed to only load the default 
> language rather than english (and as long as the requested language is not 
> the same as the default one) as fallback, so it can match the actual server 
> side behaviour, which will load the configured language (at settings) as a 
> fallback language as long as it is different from it (an from english, 
> which makes sense because django text ids are all in english).
> This change could however affect people that relies on always having an 
> english translation as fallback when the configured default language is not 
> english (does this even make sense? Would anyone do that?)
>
> After this change is done, there could be an improvement (for both js and 
> server side translations) that some people might find useful, rather than 
> always falling back to the default configured language, you could have a 
> map of fallbacks, for example, if the user requests a portuguese language, 
> but you only have english (default) and spanish (secondary), it makes more 
> sense to fallback to spanish rather than english, but if the user requests 
> russian, it makes more sense to fallback to english.
>
> El martes, 1 de marzo de 2016, 21:29:42 (UTC-3), Tim Graham escribió:
>>
>> Have you tried looking through history with git blame to find related 
>> tickets? Another tip is to search Google with a query like 
>> "javascript_catalog site:code.djangoproject.com". This will let you find 
>> tickets to see if the issue was raised before. This is how I try to answer 
>> questions like this since many of the original authors are no longer active 
>> (or at least, you can find the person who authored the code in question and 
>> try a more directed query like a ping in IRC).
>>
>> On Tuesday, March 1, 2016 at 6:23:38 PM UTC-5, Cristiano Coelho wrote:
>>>
>>> Maybe I wasn't clear neither, but the main issue is this: when using a 
>>> language equals to the default one, and if that language does not define 
>>> any translation text (because ids are the same as values so it is not 
>>> necessary), the server side translations will always correctly return the 
>>> translated texts, while the javascript won't because it always has an 
>>> english fallback.
>>> Also the code I provided should actually load the default language 
>>> translations as well (but not the english ones!) to make it behave exactly 
>>> as the server side translations.
>>>
>>

-- 
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/6f9ba995-8ca9-4b5f-bfb5-e60575abe3ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding SASL authentication support to PyLibMCCache

[Tim Graham]

As it so happens, someone else ended up tackling this problem for a 
different use case in https://github.com/django/django/pull/6233.

There's a small design discussion on the pull request about how to 
structure OPTIONS (possibly deprecating the current behavior of pylibmc 
that passes them directly to client.behaviors) if anyone would like to 
weigh in.

On Monday, February 22, 2016 at 1:36:02 PM UTC-5, Claude Paroz wrote:
>
> Le lundi 22 février 2016 13:00:31 UTC+1, Ed Morley a écrit :
>>
>> (...)
>>
>> I'm happy to put together a PR to make the impact/complexity easier to 
>> judge, if that helps?
>>
>>
> Yes, it always help to see the code. 
>  
>
>> Before I do that I would just need to know whether the `username`, 
>> `password` and `binary` fields should be added to the top level 
>> `CACHES['foo']` dict, or nested inside `OPTIONS` within that? Examples:
>> https://emorley.pastebin.mozilla.org/8858134
>>
>
> I would say that if username and password are not mandatory, put them in 
> options. But no strong opinion here.
>
> Claude
>

-- 
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/95987755-0ade-4c3d-a806-52f1b3393af5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: TransactionManagementError is raised when autocommit …

[Tore Lundqvist]

Hi, Simon

No, I would need to wrap everything i a atomic block to start the 
transaction and it's only when that outermost atomic block exits that I 
actually get a commit the nested ones just makes save point.

/Tore 

Den fredag 4 mars 2016 kl. 21:09:17 UTC+1 skrev charettes:
>
> Hi Tore,
>
> Is there a reason you can't simply wrap your updates in a 
> `transaction.atomic()` blocks?
>
> You should be able to avoid deadlocks and control exactly when data is 
> written to disk
> with this construct.
>
> Simon
>
> Le vendredi 4 mars 2016 15:02:45 UTC-5, Tore Lundqvist a écrit :
>>
>> Reply to comments in ticket: 
>> https://code.djangoproject.com/ticket/26323#comment:10
>>
>> Hi, 
>>
>> @Aagustin: I get your point but in the code I'm working on there is a lot 
>> of transaction.commit(), not to handle transactions but to manage when data 
>> is written to disk and to avoid deadlocks. Running in autocommit mode does 
>> not work, its slow and sometimes the commits is used to save in a known 
>> good state. So I disable autocommit with transaction.set_autocommit(False) 
>> and run the code with explicit commits in it and than turn autocommit on 
>> again. 
>>
>> The documentation for set_autocommit says "Once you turn autocommit off, 
>> you get the default behavior of your database adapter, and Django won’t 
>> help you." That is what I want and thats way I think that 
>> the TransactionManagementError should not de raise if your not using atomic 
>> blocks. 
>>
>

-- 
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/a6077f33-1113-4767-828c-8b2c0c77bd78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: TransactionManagementError is raised when autocommit …

[charettes]

Hi Tore,

Is there a reason you can't simply wrap your updates in a 
`transaction.atomic()` blocks?

You should be able to avoid deadlocks and control exactly when data is 
written to disk
with this construct.

Simon

Le vendredi 4 mars 2016 15:02:45 UTC-5, Tore Lundqvist a écrit :
>
> Reply to comments in ticket: 
> https://code.djangoproject.com/ticket/26323#comment:10
>
> Hi, 
>
> @Aagustin: I get your point but in the code I'm working on there is a lot 
> of transaction.commit(), not to handle transactions but to manage when data 
> is written to disk and to avoid deadlocks. Running in autocommit mode does 
> not work, its slow and sometimes the commits is used to save in a known 
> good state. So I disable autocommit with transaction.set_autocommit(False) 
> and run the code with explicit commits in it and than turn autocommit on 
> again. 
>
> The documentation for set_autocommit says "Once you turn autocommit off, 
> you get the default behavior of your database adapter, and Django won’t 
> help you." That is what I want and thats way I think that 
> the TransactionManagementError should not de raise if your not using atomic 
> blocks. 
>

-- 
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/b1e83702-f098-467d-833f-daf387bda2ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Marc Tamlyn]

Voting:

1) should there be a default?

I'm lazy, so I would be happy to have one. Where validation matters you can
change it, where it doesn't you don't have to. I'd draw an analogy to
(Positive)(Small)IntegerField - I often use the normal one when I mean some
variant of validation, or some other max/min value.

2) how to make it easy to have no limit on PG?

If it's truly pg specific, then a contrib.pg field seems fine, though
probably call it UnlimitedCharField for lack of ambiguity.

M
On 1 Mar 2016 1:11 a.m., "Markus Holtermann" 
wrote:

> From what I understand you will have a hard time doing that at all:
>
> On PG could go with a 'max_length=None' in a 3rd party app. But that
> wouldn't be supported on any other database backend. Which means you're
> limiting your app to PG. On the other hand you could make your app database
> independent by using a TextField which has pretty much the same performance
> on PG as a VARCHAR() and is available on other backends. But may perform
> bad on other backends. But there's no way to have a text of unlimited
> length on MySQL other than a TEXT column.
>
> TL;DR: you can't achieve both ways anyway. Neither now nor if we change
> the behavior of Django's max_length attribute on CharFields.
>
> /Markus
>
> On Tuesday, March 1, 2016 at 11:00:29 AM UTC+11, Cristiano Coelho wrote:
>>
>> I find that using TextField rather than CharField just to make postgres
>> use varchar() is a terrible idea, if you are implementing an reusable app
>> and it is used on a backend like MySQL where TextFields are created as text
>> columns which are horribly inneficient and should be avoided at any cost
>> you will have a really bad time.
>> I'm not sure about postgres but I want to believe that using varchar
>> without limits has also some performance considerations that should be
>> taken care of.
>>
>> El lunes, 29 de febrero de 2016, 17:58:33 (UTC-3), Shai Berger escribió:
>>>
>>> Hi,
>>>
>>> Thank you, Aymeric, for summing up the discussion this way. The division
>>> into
>>> two separate problems is indeed required, and I fully support the idea
>>> of
>>> setting max_length's default to 100 or 120.
>>>
>>> There seem to be just two points worth adding to your summary:
>>>
>>> On Monday 29 February 2016 11:19:02 Aymeric Augustin wrote:
>>> >
>>> > 2) How can we make it easy for PostgreSQL users to just use VARCHAR()?
>>> >
>>> > Since this is a PostgreSQL-specific feature, having a variant of
>>> CharField
>>> > in django.contrib.postgres that supports and perhaps even defaults to
>>> > unlimited length shouldn’t be controversial.
>>> >
>>>
>>> The first -- I believe it was raised very early on by Christophe Pettus
>>> -- is
>>> that Django already has a field that manifests on PG as VARCHAR(), and
>>> that is
>>> TextField. However, I don't like the idea that PG users should be using
>>> TextField(widget=TextInput) as a replacement for CharField; I find that
>>> counter-intuitive -- even if just because it is a "bad name". Names are
>>> important.
>>>
>>> The second -- in response to a comment made by Josh Smeaton -- is that
>>> having
>>> django.db.models.CharField with default max_lenth=N (for some finite N)
>>> and
>>> django.contrib.postgres.CharField with default max_length=None (meaning
>>> infinity) sounds like a bad idea.
>>>
>>> >
>>> > I hope this helps!
>>>
>>> I'm certain it did!
>>>
>>> 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 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/71e5e743-29bb-4dba-9bf4-6948ab2d1fa9%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/CAMwjO1Gj3E4_83qdbQmQwXe_WdTXUf7yuZ44-aQ9jgvJN9-5sg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

TransactionManagementError is raised when autocommit …

[Tore Lundqvist]

Reply to comments in ticket: 
https://code.djangoproject.com/ticket/26323#comment:10

Hi, 

@Aagustin: I get your point but in the code I'm working on there is a lot 
of transaction.commit(), not to handle transactions but to manage when data 
is written to disk and to avoid deadlocks. Running in autocommit mode does 
not work, its slow and sometimes the commits is used to save in a known 
good state. So I disable autocommit with transaction.set_autocommit(False) 
and run the code with explicit commits in it and than turn autocommit on 
again. 

The documentation for set_autocommit says "Once you turn autocommit off, 
you get the default behavior of your database adapter, and Django won’t 
help you." That is what I want and thats way I think that 
the TransactionManagementError should not de raise if your not using atomic 
blocks. 

-- 
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/13f9f465-410f-447c-8bc0-30dfff139a5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: django.contrib.mysql

[Marc Tamlyn]

One of the other reasons why contrib.postgres is in core is that it
required some changes to internals of the ORM. It's possible that all of
those we need are done now (except custom indexes) - is there anything
about contrib.mysql which would benefit from this?

I'm happy for JSONField to be made a core field on the condition that it's
underlying support is more than a text blob on all our main databases. It
sounds like this will soon be the case.

Marc

On 4 March 2016 at 09:04, Josh Smeaton  wrote:

> I agree regarding choosing the most most useful bits. When we discussed
> this at DUTH I did mention that there were some features that would be very
> difficult to get included in Django. I guess you'd have to consider whether
> or not you'd be willing to move features from django-mysql into contrib and
> how that might affect django-mysql in the longer term.  I really like the
> idea of having a contrib.mysql though, as it shows we're not just committed
> to moving postgres forward. Having a voice for mysql in the team would also
> be very helpful.
>
> Cheers
>
> On Friday, 4 March 2016 18:15:15 UTC+11, Aymeric Augustin wrote:
>>
>> Hi Adam,
>>
>> django-mysql has a rather large API surface. I think the first step would
>> be to make a list of the most stable and generally useful bits that are
>> candidate for inclusion in Django and to write that list down in a DEP.
>>
>> The fields, functions, lookups, and aggregates are good candidates. I’m
>> less sure about the QuerySet extensions because we don’t have anything
>> similar yet. We’d have to think about the implications.
>>
>> Looking forwards, django-mysql could be an experimental ground for
>> features. When they stabilize, the most common features could go into
>> django.contrib.mysql.
>>
>> Since making changes to public APIs is a pain, you only want to put code
>> in Django when it’s done. To a lesser extent, we have Python’s “standard
>> library is where modules go to die” problem.
>>
>> It would obviously help if other community members expressed interest in
>> django.contrib.mysql or, even better, intent to help maintain it in the
>> future.
>>
>> I hope this helps,
>>
>> --
>> Aymeric.
>>
>> PS: if this plan comes to fruition, most likely you’ll get commit access
>> along the way ;-)
>>
>>
>> On 04 Mar 2016, at 00:09, Adam Johnson  wrote:
>>
>> The *django.contrib.postgres* docs state:
>>
>> There is no fundamental reason why (for example) a contrib.mysql module
>>> does not exist
>>
>>
>> *Well...* over the past year and a bit I've been developing
>> Django-MySQL. It has a ton of features specific to MySQL and/or MariaDB.
>> For a quick tour of the features, see the exposition in the documentation:
>> https://django-mysql.readthedocs.org/en/latest/exposition.html (it's not
>> all suitable for Django core, some is kinda hacky (but well tested!))
>>
>> At DUTH in November I talked with Josh Smeaton about posting a suggestion
>> here for *django.contrib.mysql*. Since then, I've simply been
>> lazy/forgetful, but now I'm here getting round to it.
>>
>> I'm also a bit motivated by my recent completion of its *JSONField* for
>> MySQL 5.7+ which is very similar to the *contrib.postgres* one, copying
>> and adapting large parts of code from Marc Tamlyn's work. We all know how
>> much everyone loves JSON these days. If anything, this could be a core
>> field rather than a *contrib* one - Oracle and SQLite also have JSON
>> capabilities now. JSON everywhere!
>>
>> Anyway... what's the interest in *django.contrib.mysql*? And where woudl
>> we go from here...
>>
>> --
>> 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/ed9245ea-f908-4c1c-91ad-cb94f0147959%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/562f8c3e-4bf1-47cf-9a98-1a6f9b171528%40googlegroups.com
> 

Re: Proposal: django.contrib.mysql

[Josh Smeaton]

I agree regarding choosing the most most useful bits. When we discussed 
this at DUTH I did mention that there were some features that would be very 
difficult to get included in Django. I guess you'd have to consider whether 
or not you'd be willing to move features from django-mysql into contrib and 
how that might affect django-mysql in the longer term.  I really like the 
idea of having a contrib.mysql though, as it shows we're not just committed 
to moving postgres forward. Having a voice for mysql in the team would also 
be very helpful.

Cheers

On Friday, 4 March 2016 18:15:15 UTC+11, Aymeric Augustin wrote:
>
> Hi Adam,
>
> django-mysql has a rather large API surface. I think the first step would 
> be to make a list of the most stable and generally useful bits that are 
> candidate for inclusion in Django and to write that list down in a DEP.
>
> The fields, functions, lookups, and aggregates are good candidates. I’m 
> less sure about the QuerySet extensions because we don’t have anything 
> similar yet. We’d have to think about the implications.
>
> Looking forwards, django-mysql could be an experimental ground for 
> features. When they stabilize, the most common features could go into 
> django.contrib.mysql.
>
> Since making changes to public APIs is a pain, you only want to put code 
> in Django when it’s done. To a lesser extent, we have Python’s “standard 
> library is where modules go to die” problem.
>
> It would obviously help if other community members expressed interest in 
> django.contrib.mysql or, even better, intent to help maintain it in the 
> future.
>
> I hope this helps,
>
> -- 
> Aymeric.
>
> PS: if this plan comes to fruition, most likely you’ll get commit access 
> along the way ;-)
>
>
> On 04 Mar 2016, at 00:09, Adam Johnson > 
> wrote:
>
> The *django.contrib.postgres* docs state:
>
> There is no fundamental reason why (for example) a contrib.mysql module 
>> does not exist
>
>
> *Well...* over the past year and a bit I've been developing Django-MySQL. 
> It has a ton of features specific to MySQL and/or MariaDB. For a quick tour 
> of the features, see the exposition in the documentation: 
> https://django-mysql.readthedocs.org/en/latest/exposition.html (it's not 
> all suitable for Django core, some is kinda hacky (but well tested!))
>
> At DUTH in November I talked with Josh Smeaton about posting a suggestion 
> here for *django.contrib.mysql*. Since then, I've simply been 
> lazy/forgetful, but now I'm here getting round to it.
>
> I'm also a bit motivated by my recent completion of its *JSONField* for 
> MySQL 5.7+ which is very similar to the *contrib.postgres* one, copying 
> and adapting large parts of code from Marc Tamlyn's work. We all know how 
> much everyone loves JSON these days. If anything, this could be a core 
> field rather than a *contrib* one - Oracle and SQLite also have JSON 
> capabilities now. JSON everywhere!
>
> Anyway... what's the interest in *django.contrib.mysql*? And where woudl 
> we go from here...
>
> -- 
> 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/ed9245ea-f908-4c1c-91ad-cb94f0147959%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/562f8c3e-4bf1-47cf-9a98-1a6f9b171528%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SQL ALchemy support on django

[Asif Saifuddin]

Hi,

I will be working on preparing a proposal for sql-alchemy support on 
django. [thorugh model meta]. 

Thanks

On Wednesday, September 16, 2015 at 2:35:15 PM UTC+6, Asif Saifuddin wrote:
>
> Hi,
>
>
> How much difficult it will be to add SQLalchemy support to django? what 
> are the technical difficulties? And which are the ways to add sqlalchemy 
> support to django?
>
> As SQLalchemy is separated in core and orm will it be wise to use 
> sqlalchemy core as the backend for django orm? Or  through the meta api? 
> any suggestion or direction to the solutions?
>
> The available 3rd party packages seems to be incomplete.
>
>
> Regards
>
> Asif
>

-- 
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/57f06658-bce9-4d1b-80d6-d4e5bee3cd5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.