Re: Revisiting multiline tags
On 12/03/16 11:47, Nathan Cox wrote: I don't understand why this conversation has had to go on for this long. The original post was in February of 2012, and it is now March of 2016. That's four years of discussion that basically boils down to a couple of purists insisting that their coding style is the only coding style, fits every possible scenario and is beautiful, while a much larger group comes up with scenarios where the given style guide is counterintuitive and difficult to read. I think, really, the core issue is a philosophical one, and it comes down to this: Will making this change encourage people to put more work in templates? Or, more, will it stop discouraging people from providing clean, simple interfaces in the context, instead of requiring template authors to do more work? Personally, I think it's a tiny issue drastically outweighed by the advantages -- especially for the translation cases raised. I think the salient fact here is that templating languages are supposed to be supersets of HTML, and as supersets should respect the native abilities of their parents. I disagree here. Whilst the most common use is for rendering HTML, it is frequently used for other cases. Also, DTL quite specifically is NOT html-like to make it more widely usable. With HTML it is common and accepted to break tags with many attributes across multiple lines so that the code itself is easy to read (i.e., "visually parse", a term used frequently in this thread). This same convention extends into the Python world, where long lines can easily be broken down using parenthesis to maintain language constraints while allowing for ease of readability. In fact, PEP8 specifically prohibits lines longer than 80 characters, and even people who break that generally respect something along the lines of 99. Two Scoops will tell you that any community software should be a hard limit of 80, while internal projects can be allowed to go to 99 with group consensus. From memory, Django itself uses a 119 char line limit - in deference to the prevalence of widescreen monitors. Even so, I do agree long lines reduce readability. So you have a python templating language for generating HTML, two languages which both embrace multi-line statements merging together, but we can't agree that it should probably also support this? Well, we have a templating language... implemented in Python - but quite specifically _not_ python itself... primarily for rendering HTML, but specifically engineered to not be limited to it... So you can see how some might think this argument is weak... I think this conversation needs to come to a conclusion, and that conclusion should be simple. Several people have asked a very simple question of the purists: what is the "correct" way of writing tags which by nature need to be very long, without line breaks and without them being 400 characters long. If no acceptable answer can be given, we need to just implement the line break mechanic and give the developers back their whitespace. As pointed out by Josh in another email, I wrote a patch to permit multi-line tags. I asked for feedback. I got _none_. If people really wanted this feature, why didn't we hear more about it? What can we do to get more people to know about it, and to give more feedback? I would recommend you review the history of this discussion, collect the pros and cons, formulate a DEP, and we can go from there. I'm quite sure the patch will still work fine. -- C -- 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/56E39BA0.2070007%40tinbrain.net. For more options, visit https://groups.google.com/d/optout.
Re: Revisiting multiline tags
Funkybob (Curtis Maloney) implemented a multiline template tag patch nearly two years ago. He asked for feedback a number of times and received none. I think there's enough support here that if someone were to implement a patch, it'd probably be accepted. Adding the same argument as to why multiline tags would be useful isn't helpful anymore. The arguments have been made. Adrian requested the pros/cons be written up as a DEP. Curtis began one but it seems to have disappeared, I assume because there was lack of review or interest. If you feel strongly enough for this change please feel free to write up a DEP or even a patch that implements multiline tags, paying particular attention to ensure performance isn't hindered (as discussed above). Core devs have only so much time to work on features. If a feature isn't more important to them than something else, chances are it won't get implemented by them. Everyone is free to (and encouraged to!) implement features themselves. A core dev will review it. Non core developers are also free to (and encouraged to) review it. I know it sounds like I'm putting forth the "PRs accepted" brush off line, but there's elements of truth in that statement. Curtis wrote a patch and no one tested it. How important is this feature again? On Saturday, 12 March 2016 11:54:46 UTC+11, Nathan Cox wrote: > > I don't understand why this conversation has had to go on for this long. > > The original post was in February of 2012, and it is now March of 2016. > That's four years of discussion that basically boils down to a couple of > purists insisting that their coding style is the only coding style, fits > every possible scenario and is beautiful, while a much larger group comes > up with scenarios where the given style guide is counterintuitive and > difficult to read. > -- 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/e40ff1fe-3cca-468a-9837-c5b7b53c0c5e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Revisiting multiline tags
I don't understand why this conversation has had to go on for this long. The original post was in February of 2012, and it is now March of 2016. That's four years of discussion that basically boils down to a couple of purists insisting that their coding style is the only coding style, fits every possible scenario and is beautiful, while a much larger group comes up with scenarios where the given style guide is counterintuitive and difficult to read. I think the salient fact here is that templating languages are supposed to be supersets of HTML, and as supersets should respect the native abilities of their parents. With HTML it is common and accepted to break tags with many attributes across multiple lines so that the code itself is easy to read (i.e., "visually parse", a term used frequently in this thread). This same convention extends into the Python world, where long lines can easily be broken down using parenthesis to maintain language constraints while allowing for ease of readability. In fact, PEP8 specifically prohibits lines longer than 80 characters, and even people who break that generally respect something along the lines of 99. Two Scoops will tell you that any community software should be a hard limit of 80, while internal projects can be allowed to go to 99 with group consensus. So you have a python templating language for generating HTML, two languages which both embrace multi-line statements merging together, but we can't agree that it should probably also support this? I think this conversation needs to come to a conclusion, and that conclusion should be simple. Several people have asked a very simple question of the purists: what is the "correct" way of writing tags which by nature need to be very long, without line breaks and without them being 400 characters long. If no acceptable answer can be given, we need to just implement the line break mechanic and give the developers back their whitespace. -- 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/06029153-7606-4047-b6a4-7d0d1b9dd04d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Improving MSSQL and Azure SQL support on Django
The slowness of progress on django-mssql is entirely my fault due to the personal reasons I briefly mentioned during DUTH. Microsoft has offered help and in my opinion seems very eager to start pushing pull requests, but I haven't had the bandwidth to direct their efforts. I should have more bandwidth starting the end of this month when things are finally settled. Regards, Michael Manfre On Fri, Mar 11, 2016 at 1:54 PM, Tim Graham wrote: > Yes, I wonder if Microsoft abandoned the idea of providing engineering > resources to help out projects like django-mssql or if things are just > moving really slowly? I'm not aware of any follow up related to that idea > since Michael, Michiya, and I visited Microsoft in October. > > > On Wednesday, March 9, 2016 at 9:43:16 PM UTC-5, Cristiano Coelho wrote: >> >> "Improve documentation/examples [decrease confusion]: There's already so >> much awesome content out there on getting started with Django (but not many >> are referencing MSSQL as the db of choice or why MSSQL is a great option)." >> >> I wouldn't think of MSSQL as a great option for django at least until it >> is supported natively and not through 3rd party apps which are always >> behind django updates. >> >> El martes, 8 de marzo de 2016, 23:20:58 (UTC-3), Vin Yu escribió: >>> >>> Hey Tim, >>> >>> We've gotten lots of questions about the tools when we announced SQL >>> Server on Linux. I am curious; what are the DB management/development tasks >>> that are being performed by your coworkers? What are they using SSMS for? I >>> am interested in learning more. [Perhaps we can follow up by email as this >>> seens off-topic here :) ] >>> >>> In terms of strengthening the story for MSSQL-Django, I think there is a >>> little bit of both difficulty and confusion over options; here are some >>> ideas that we are working on and could solve these issues: >>> >>>- Improve documentation/examples [decrease confusion]: There's >>>already so much awesome content out there on getting started with Django >>>(but not many are referencing MSSQL as the db of choice or why MSSQL is a >>>great option). >>>- Improve getting started experience [decrease difficulty]: Getting >>>MSSQL for development (free and easy/fast set up) is hard today;this is >>> on >>>MSFT to improve this experience. >>> >>> We want to help provide better developer experiences for those who want >>> to create new Django apps + MSSQL databases and if MSSQL were in the core, >>> it would definitely help with that. This would increase usage and is >>> something we are striving to achieve. We will continue to work with the >>> community to make this happen. >>> >>> =) , >>> Vin >>> >>> >>> On Tuesday, 8 March 2016 10:13:34 UTC-8, Tim Allen wrote: [slightly off-topic] I'm wondering if this will extend to SQL Server Management Studio. While I'm mainly a command line basher, many of coworkers are married to the GUI. I've found SSMS blows the competition out of the water when it comes to DB management GUIs. I'm wondering if this means SSMS will run on Linux (or Mac) eventually. This is certainly very big news. I wouldn't be shocked to some day see Windows itself running on the Linux Kernel. Meet, how can we help strengthen the story for MSSQL-Django? It seems we have a chicken and egg problem here. A very small amount of Django sites use SQL Server, but is that because of the difficulty in the available stack and confusion over options? Would usage increase if provided in core? On Monday, March 7, 2016 at 6:03:29 PM UTC-5, Josh Smeaton wrote: > > Wow, that's really great news! I haven't used mssql for a number of > years but it was always very nice to work with. Having it available to run > on linux will make it much easier for the Django community to test against > mssql, provided we're able to get/develop an appropriate driver and > backend. > > Cheers > > On Tuesday, 8 March 2016 09:37:06 UTC+11, Meet Bhagdev wrote: >> >> Hi all, >> >> On interacting with several Django developers and committers, one of >> the questions often came up, can I use SQL Server on non Window OS's? I >> wanted to share that today Microsoft announced SQL Server availibility on >> Linux - >> https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/ >> . >> >> While there is still work needed to strengthen the MSSQL-Django >> story, we hope this aids more Linux developers to give SQL Server a shot. >> Let me know of your thoughts and questions :) >> >> Cheers, >> Meet >> >> On Monday, February 22, 2016 at 4:54:38 PM UTC-8, Vin Yu wrote: >>> >>> Hey Folks, >>> >>> My name is Vin and I work with Meet in the Microsoft SQL Server >>> team. Just wanted to let you all know we are still looking into how we >>> can >>> better impro
Re: Improving MSSQL and Azure SQL support on Django
Yes, I wonder if Microsoft abandoned the idea of providing engineering resources to help out projects like django-mssql or if things are just moving really slowly? I'm not aware of any follow up related to that idea since Michael, Michiya, and I visited Microsoft in October. On Wednesday, March 9, 2016 at 9:43:16 PM UTC-5, Cristiano Coelho wrote: > > "Improve documentation/examples [decrease confusion]: There's already so > much awesome content out there on getting started with Django (but not many > are referencing MSSQL as the db of choice or why MSSQL is a great option)." > > I wouldn't think of MSSQL as a great option for django at least until it > is supported natively and not through 3rd party apps which are always > behind django updates. > > El martes, 8 de marzo de 2016, 23:20:58 (UTC-3), Vin Yu escribió: >> >> Hey Tim, >> >> We've gotten lots of questions about the tools when we announced SQL >> Server on Linux. I am curious; what are the DB management/development tasks >> that are being performed by your coworkers? What are they using SSMS for? I >> am interested in learning more. [Perhaps we can follow up by email as this >> seens off-topic here :) ] >> >> In terms of strengthening the story for MSSQL-Django, I think there is a >> little bit of both difficulty and confusion over options; here are some >> ideas that we are working on and could solve these issues: >> >>- Improve documentation/examples [decrease confusion]: There's >>already so much awesome content out there on getting started with Django >>(but not many are referencing MSSQL as the db of choice or why MSSQL is a >>great option). >>- Improve getting started experience [decrease difficulty]: Getting >>MSSQL for development (free and easy/fast set up) is hard today;this is >> on >>MSFT to improve this experience. >> >> We want to help provide better developer experiences for those who want >> to create new Django apps + MSSQL databases and if MSSQL were in the core, >> it would definitely help with that. This would increase usage and is >> something we are striving to achieve. We will continue to work with the >> community to make this happen. >> >> =) , >> Vin >> >> >> On Tuesday, 8 March 2016 10:13:34 UTC-8, Tim Allen wrote: >>> >>> [slightly off-topic] I'm wondering if this will extend to SQL Server >>> Management Studio. While I'm mainly a command line basher, many of >>> coworkers are married to the GUI. I've found SSMS blows the competition out >>> of the water when it comes to DB management GUIs. I'm wondering if this >>> means SSMS will run on Linux (or Mac) eventually. >>> >>> This is certainly very big news. I wouldn't be shocked to some day see >>> Windows itself running on the Linux Kernel. >>> >>> Meet, how can we help strengthen the story for MSSQL-Django? It seems we >>> have a chicken and egg problem here. A very small amount of Django sites >>> use SQL Server, but is that because of the difficulty in the available >>> stack and confusion over options? Would usage increase if provided in core? >>> >>> On Monday, March 7, 2016 at 6:03:29 PM UTC-5, Josh Smeaton wrote: Wow, that's really great news! I haven't used mssql for a number of years but it was always very nice to work with. Having it available to run on linux will make it much easier for the Django community to test against mssql, provided we're able to get/develop an appropriate driver and backend. Cheers On Tuesday, 8 March 2016 09:37:06 UTC+11, Meet Bhagdev wrote: > > Hi all, > > On interacting with several Django developers and committers, one of > the questions often came up, can I use SQL Server on non Window OS's? I > wanted to share that today Microsoft announced SQL Server availibility on > Linux - > https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/ > . > > While there is still work needed to strengthen the MSSQL-Django story, > we hope this aids more Linux developers to give SQL Server a shot. Let me > know of your thoughts and questions :) > > Cheers, > Meet > > On Monday, February 22, 2016 at 4:54:38 PM UTC-8, Vin Yu wrote: >> >> Hey Folks, >> >> My name is Vin and I work with Meet in the Microsoft SQL Server team. >> Just wanted to let you all know we are still looking into how we can >> better >> improve and support MSSQL for the Django framework. We’ll continue to >> sync >> with Michael and let you know of any updates soon. >> >> Christiano and Tim - thanks for sharing your interest and sharing how >> you are using Django with MSSQL. It's great to learn from your >> scenarios. >> >> If you have any concerns, questions or comments feel free to reach >> out to me at vinsonyu[at]microsoft.com > > -- You received this message because you are subs
Re: Surprising behaviour in case of exception in form widget when DEBUG=False
Right, I see the log entries. Good to know there's a way to log them, for
those who use sentry it will be even easier to notice this problem,
just ensure you're logging WARNING messages.
Thanks
Federico
On Friday, March 11, 2016 at 1:18:27 PM UTC+1, Tim Graham wrote:
>
> Yes, I think it's {% include %} rendering an empty string if there's an
> exception. In Django 1.9, we added a logger for these exceptions to make
> debugging easier:
> https://docs.djangoproject.com/en/stable/topics/logging/#django-template.
>
> On Friday, March 11, 2016 at 6:30:35 AM UTC-5, Federico Capoano wrote:
>>
>> This never happened to me and I find it very strange. Maybe it's a bug or
>> maybe it's the intended behaviour, but I find it REALLY strange.
>>
>> Consider a widget which, for some reason, raises an exception:
>>
>> class CoolWidget(AdminTextareaWidget):
>> def render(self, name, value, attrs={}):
>> WRONG()
>> return super(JsonSchemaWidget, self).render(name, value, attrs)
>>
>> The widget is included in an admin form like:
>>
>> class PizzaForm(forms.ModelForm):
>> class Meta:
>> model = Pizza
>> exclude = []
>> widgets = {'toppings': CoolWidget}
>>
>>
>> class PizzaAdmin(ModelAdmin):
>> form = TemplateForm
>>
>> Now, if DEBUG is True, trying to open the relative pizza change or add
>> form will result in:
>>
>> NameError: name 'WRONG' is not defined
>>
>> When DEBUG to False what I see is really strange:
>>
>> I get an empty change/add form!
>>
>>
>>
>>
>>
>> Now suppose that the condition that raises the exception happens only on
>> a remote server
>>
>> which has DEBUG=False. The exception happens because the configuration of
>> a django project
>>
>> has not been updated correctly yet.
>>
>>
>> Instead of failing loud, it will fail silently, leaving an empty
>> add/change form.
>>
>>
>> Is it the intended behaviour? Or a bug?
>>
>> I guess it is related due to the fact that template errors are silenced.
>>
>> Federico
>>
>
--
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/c6158dd8-cc88-4c26-ac25-4b86eef2ea3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Choosing migration with relative syntax
You can always have a y/N-question to limit these cases. Though, I think this is a problem as it is right now too, because you can always do a typo. /Joakim Den fredag 11 mars 2016 kl. 14:06:42 UTC+1 skrev Markus Holtermann: > > Hi Joakim, > > thank you for your proposal. > > I don't think this is a good idea because you can easily accidentally undo > too many migrations which would inevitably will result in data loss. You > don't have the data loss problem in Git as you can always recover by using > `git reflog` to go back and e.g. undo an incorrect rebase. However, when > you remove a field from a database table the data is pretty much lost. > > Cheers, > > /Markus > > On Friday, March 11, 2016 at 11:39:53 PM UTC+11, Joakim Saario wrote: >> >> Hello! >> >> Today if you just need to unmigrate the *n* migrations before the last >> one you would >> typically run `migrate --list` and then `migrate >> ` where >> `migration_name` is the migration you want to roll back to. >> >> To reduce the steps of this procedure i think it would be nice to >> introduce >> a syntax similar to how commits in for example git works. I.e `git show >> HEAD^` >> for the previous commit and `git show HEAD~2` for the one before that. >> It would also be good to support the `git show (^+)|(~\d)` >> variant >> of this to be able to choose the origin. >> >> For this to work good for the normal case, there need to be a magic word >> that maps to the latest migration available and/or the latest applied >> migration. >> >> I can clearly see a use case for this as I can imagine that the most >> common >> operation besides applying all unmigrated migrations is to roll back *n* >> migrations. >> >> Does this sounds like a good idea? >> > -- 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/46b90e2f-e14d-41c9-8ac8-f7758e3a3d46%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Choosing migration with relative syntax
Hi Joakim, thank you for your proposal. I don't think this is a good idea because you can easily accidentally undo too many migrations which would inevitably will result in data loss. You don't have the data loss problem in Git as you can always recover by using `git reflog` to go back and e.g. undo an incorrect rebase. However, when you remove a field from a database table the data is pretty much lost. Cheers, /Markus On Friday, March 11, 2016 at 11:39:53 PM UTC+11, Joakim Saario wrote: > > Hello! > > Today if you just need to unmigrate the *n* migrations before the last > one you would > typically run `migrate --list` and then `migrate > ` where > `migration_name` is the migration you want to roll back to. > > To reduce the steps of this procedure i think it would be nice to introduce > a syntax similar to how commits in for example git works. I.e `git show > HEAD^` > for the previous commit and `git show HEAD~2` for the one before that. > It would also be good to support the `git show (^+)|(~\d)` > variant > of this to be able to choose the origin. > > For this to work good for the normal case, there need to be a magic word > that maps to the latest migration available and/or the latest applied > migration. > > I can clearly see a use case for this as I can imagine that the most common > operation besides applying all unmigrated migrations is to roll back *n* > migrations. > > Does this sounds like a good idea? > -- 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/a096ca85-b9f1-42bb-a606-42d1d2978a66%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: TransactionManagementError is raised when autocommit …
On 11 Mar 2016, at 10:28, Tore Lundqvist wrote: > Given MySQL’s interesting approach to transactional integrity, you can call > transaction.set_rollback(False) after a query that failed with an > IntegrityError and keep going. > > You can't use set_rollback() outside an atomic block so that not an option > for me. Indeed. (I realized that after sending my email and forgot to send a correction.) -- Aymeric. -- 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/1C7E9525-0536-415D-8223-554FFB511CC8%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
Choosing migration with relative syntax
Hello! Today if you just need to unmigrate the *n* migrations before the last one you would typically run `migrate --list` and then `migrate ` where `migration_name` is the migration you want to roll back to. To reduce the steps of this procedure i think it would be nice to introduce a syntax similar to how commits in for example git works. I.e `git show HEAD^` for the previous commit and `git show HEAD~2` for the one before that. It would also be good to support the `git show (^+)|(~\d)` variant of this to be able to choose the origin. For this to work good for the normal case, there need to be a magic word that maps to the latest migration available and/or the latest applied migration. I can clearly see a use case for this as I can imagine that the most common operation besides applying all unmigrated migrations is to roll back *n* migrations. Does this sounds like a good idea? -- 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/9ef49cce-5eb6-4a52-85e1-fd507b28991a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Surprising behaviour in case of exception in form widget when DEBUG=False
Yes, I think it's {% include %} rendering an empty string if there's an
exception. In Django 1.9, we added a logger for these exceptions to make
debugging easier:
https://docs.djangoproject.com/en/stable/topics/logging/#django-template.
On Friday, March 11, 2016 at 6:30:35 AM UTC-5, Federico Capoano wrote:
>
> This never happened to me and I find it very strange. Maybe it's a bug or
> maybe it's the intended behaviour, but I find it REALLY strange.
>
> Consider a widget which, for some reason, raises an exception:
>
> class CoolWidget(AdminTextareaWidget):
> def render(self, name, value, attrs={}):
> WRONG()
> return super(JsonSchemaWidget, self).render(name, value, attrs)
>
> The widget is included in an admin form like:
>
> class PizzaForm(forms.ModelForm):
> class Meta:
> model = Pizza
> exclude = []
> widgets = {'toppings': CoolWidget}
>
>
> class PizzaAdmin(ModelAdmin):
> form = TemplateForm
>
> Now, if DEBUG is True, trying to open the relative pizza change or add
> form will result in:
>
> NameError: name 'WRONG' is not defined
>
> When DEBUG to False what I see is really strange:
>
> I get an empty change/add form!
>
>
>
>
>
> Now suppose that the condition that raises the exception happens only on a
> remote server
>
> which has DEBUG=False. The exception happens because the configuration of
> a django project
>
> has not been updated correctly yet.
>
>
> Instead of failing loud, it will fail silently, leaving an empty
> add/change form.
>
>
> Is it the intended behaviour? Or a bug?
>
> I guess it is related due to the fact that template errors are silenced.
>
> Federico
>
--
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/086f4acb-524b-4559-9b51-f1fdc2077eaf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Surprising behaviour in case of exception in form widget when DEBUG=False
This never happened to me and I find it very strange. Maybe it's a bug or
maybe it's the intended behaviour, but I find it REALLY strange.
Consider a widget which, for some reason, raises an exception:
class CoolWidget(AdminTextareaWidget):
def render(self, name, value, attrs={}):
WRONG()
return super(JsonSchemaWidget, self).render(name, value, attrs)
The widget is included in an admin form like:
class PizzaForm(forms.ModelForm):
class Meta:
model = Pizza
exclude = []
widgets = {'toppings': CoolWidget}
class PizzaAdmin(ModelAdmin):
form = TemplateForm
Now, if DEBUG is True, trying to open the relative pizza change or add form
will result in:
NameError: name 'WRONG' is not defined
When DEBUG to False what I see is really strange:
I get an empty change/add form!
Now suppose that the condition that raises the exception happens only on a
remote server
which has DEBUG=False. The exception happens because the configuration of a
django project
has not been updated correctly yet.
Instead of failing loud, it will fail silently, leaving an empty add/change
form.
Is it the intended behaviour? Or a bug?
I guess it is related due to the fact that template errors are silenced.
Federico
--
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/e5f6999e-b94b-4ecc-a14c-02c01c789f09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: TransactionManagementError is raised when autocommit …
> Specifically, could you try adding `self.needs_rollback = False` at the > bottom of the `BaseDatabaseWrapper.rollback()` and tell me if that helps? > > Yes, this helps! With this change I can make it work without bypassing the public API. > > > > On 07 Mar 2016, at 12:55, Tore Lundqvist > > wrote: > > > an example of when it happens is when: > > Starting with auto commit on. > transaction.set_autocommit(False) > ... a lot of time passes without the connection being used so it times > out > close_old_connections() > > > There’s a long discussion of this use case here: > https://code.djangoproject.com/ticket/21597. > > Now autocommit is on again. I'm not saying that it's a bug, but it's > inconvenient. > > > This surprises me. The connection shouldn’t reopen at all. It should > become unusable, for the reasons explained in that issue (ticket 21597). > Ticket 21597 seems to be the same problem I have. I Think the timeout exception does not aper until you try to use the timed out connection and close_old_connections() closes it and solves problem. I guess its a similar solution to closing the connection before the time it's not used. You can set autocommit to false right after closing the connection, you just have to know that closing the connection also resets the autocommit setting. > > > Given MySQL’s interesting approach to transactional integrity, you can > call transaction.set_rollback(False) after a query that failed with an > IntegrityError and keep going. > You can't use set_rollback() outside an atomic block so that not an option for me. Thanks Tore -- 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/34393e05-f7fb-4d58-bc38-d125de2d42bc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
