Re: LiveServerTestCase, and override_settings(DEBUG=True)
On 19 déc. 2013, at 02:14, Russell Keith-Magee wrote: > The upside - If you add MEDIA_ROOT='/media/' to settings.py, the problem goes > away, because it gives the media layer something to match against that won't > catch all files. I hit that issue a month ago and filed https://code.djangoproject.com/ticket/21451 — with pretty much the same analysis. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/F5A8B675-0B86-4C35-BEC3-CEE87D9DB1FC%40polytechnique.org. For more options, visit https://groups.google.com/groups/opt_out.
Re: LiveServerTestCase, and override_settings(DEBUG=True)
Thanks gang. @Russell, I assume you meant set MEDIA_URL = "/media/" That works if I do it in settings.py. Interestingly, it doesn't work if I try and do it via override_settings? On Thursday, 19 December 2013 08:16:59 UTC, Aymeric Augustin wrote: > > On 19 déc. 2013, at 02:14, Russell Keith-Magee > > > wrote: > > > The upside - If you add MEDIA_ROOT='/media/' to settings.py, the problem > goes away, because it gives the media layer something to match against that > won't catch all files. > > I hit that issue a month ago and filed > https://code.djangoproject.com/ticket/21451 — with pretty much the same > analysis. > > -- > Aymeric. > -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/476680f5-4af7-4fa3-98c3-077eb29d60c3%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Problem with number format when not using L10N
Forgive me if at some point was arrogant, it was not my intention to impose my judgment or criticize, for me, the best framework that exists. Maybe I was not regarded with good intentions and therefore I believe the answers were focused to dodge my proposal.Most likely I knew not express well, beg a thousand pardons. The truth is that my problem is not yet solved and the ticket was closed. Later I will address the problem and my suggestion otherwise. For now, thank you, Best Regards El martes, 3 de diciembre de 2013 11:37:28 UTC-5, Claude Paroz escribió: > > This is the topic of https://code.djangoproject.com/ticket/21544 where > you can read my position. > -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7e2d0ab4-87b9-4f2f-b0fd-6ce734222c49%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Problem with number format when not using L10N
Hi, On Thursday 19 December 2013 05:25:11 Yonel Ceruto González wrote: > Forgive me if at some point was arrogant, it was not my intention to impose > my judgment or criticize, for me, the best framework that exists. Maybe I > was not regarded with good intentions and therefore I believe the answers > were focused to dodge my proposal.Most likely I knew not express well, beg > a thousand pardons. As the person who closed the ticket, your mail here indicates that I may have been too harsh, and I apologize for that. I would like to assure you that your intentions appear good, and your proposal was rejected purely on technical reasons, mostly according to the documentation of USE_THOUSAND_SEPARATOR and USE_L10N. However, having looked again, I now think that you do have a case -- while for the settings you pointed to, the documentation strongly implies the current behavior, the documentation for NUMBER_GROUPING and THOUSAND_SEPARATOR does support your interpretation (and in your first message you mentioned having set NUMBER_GROUPING=3). For both these settings, the documentation says: Note that if USE_L10N is set to True, then the locale-dictated format has higher precedence and will be applied instead. So -- to me, it looks like the documentation is not entirely consistent, and should be clarified; and while changing the behavior would be problematic, changing it to match (some) documentation should be a possibility. I'm waiting for other opinions -- in particular, anyone involved with the introduction of these settings, who can explain the original intentions -- to decide if we should reopen the ticket[1] as is or change it to a documentation ticket. Shai. [1] https://code.djangoproject.com/ticket/21544 -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1516598.QbdADRIKfy%40deblack. For more options, visit https://groups.google.com/groups/opt_out.
Re: LiveServerTestCase, and override_settings(DEBUG=True)
On Thu, Dec 19, 2013 at 7:36 PM, Harry Percival wrote: > Thanks gang. > > @Russell, I assume you meant set MEDIA_URL = "/media/" > Heh. Now we're even on really dumb typos :-) > That works if I do it in settings.py. Interestingly, it doesn't work if I > try and do it via override_settings? > I'd need to go digging to be sure, but I'm going to guess that this is just an ordering thing. The live server is set up fairly early in test setup, and the MEDIA_URL setting is baked into the Media handler at time of construction, not being read from settings on demand. However, the DEBUG setting *is* read on demand. @override_settings applies to the individual test, so the setup (or, at least, the bits that involve the live server setup) are probably being invoked in pre-override conditions. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq8499xxh%3D6KU1K-wiqKH4B1-BxWnppZU%2BSUZ_u-2c_E339Q%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Problem with number format when not using L10N
I recall helping someone on #django with something similar to this, where the documentation, logical expectations and actual code went in rather different directions. There was a condition where despite the setting being observed at one layer, a lower layer then went and ignored it anyway... will have to dig it up again... -- Curtis On 20 December 2013 08:19, Shai Berger wrote: > Hi, > > On Thursday 19 December 2013 05:25:11 Yonel Ceruto González wrote: > > Forgive me if at some point was arrogant, it was not my intention to > impose > > my judgment or criticize, for me, the best framework that exists. Maybe I > > was not regarded with good intentions and therefore I believe the answers > > were focused to dodge my proposal.Most likely I knew not express well, > beg > > a thousand pardons. > > As the person who closed the ticket, your mail here indicates that I may > have > been too harsh, and I apologize for that. I would like to assure you that > your > intentions appear good, and your proposal was rejected purely on technical > reasons, mostly according to the documentation of USE_THOUSAND_SEPARATOR > and > USE_L10N. > > However, having looked again, I now think that you do have a case -- while > for > the settings you pointed to, the documentation strongly implies the current > behavior, the documentation for NUMBER_GROUPING and THOUSAND_SEPARATOR does > support your interpretation (and in your first message you mentioned > having set > NUMBER_GROUPING=3). For both these settings, the documentation says: > > Note that if USE_L10N is set to True, then the locale-dictated > format has > higher precedence and will be applied instead. > > So -- to me, it looks like the documentation is not entirely consistent, > and > should be clarified; and while changing the behavior would be problematic, > changing it to match (some) documentation should be a possibility. > > I'm waiting for other opinions -- in particular, anyone involved with the > introduction of these settings, who can explain the original intentions -- > to > decide if we should reopen the ticket[1] as is or change it to a > documentation > ticket. > > Shai. > > [1] https://code.djangoproject.com/ticket/21544 > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" 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 http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/1516598.QbdADRIKfy%40deblack > . > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAG_XiSAi1yU1XwxR%2B_TSvgVi8VdYrezqSM5LUdc_QTUaqeU%3D%2Bw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: LiveServerTestCase, and override_settings(DEBUG=True)
On Wed, Dec 18, 2013 at 12:57 PM, Harry Percival wrote: > Django's test runner overrides your settings to force DEBUG to be True, > which I understand the intention behind, but it is occasionally annoying. > One solution for those cases is to use `override_settings`, but that has > very weird effects when using `LiveServerTestCase`. What version of Django are you using? -- Ramiro Morales @ramiromorales -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAO7PdF8baK65P2%2BZnD21mWD_tKtK5TvX1NVUWYs2WOOt7hFfYQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
SchemaEditor Enhancements
I just started to work on Django 1.7 support for django-mssql and I don't remember if it's too far along to get API changes in for the schema editor? I've hit a few road blocks with the current implementation of BaseSchemaEditor. I've only just started to get up to speed with the new changes, so please bear with me. What the API seems to be lacking, at least for my needs right now, is more hooks to execute the proper SQL. There exists an alter_db_table method that acts as a shim for sql_rename_table, but such a hook doesn't exist for sql_rename_column. I need both of these because MSSQL uses a stored procedure to rename objects [1], which needs the table and column names to be strings that haven't passed through quote_name(). The second API issue I've run in to is that MSSQL's equivalent to DROP DEFAULT (sql_alter_column_no_default) is to drop a named constraint. To be able to do this, I need to be able to define the column's DEFAULT as a named constraint (sql_alter_column_default). If the hooked method for these were provided with the model and column name, that seems like it would be sufficient for me to be able to generate a consistent, unique constraint name for both of those. The above would work when the default constraint was named. If its name is not known (e.g. random constraint name for columns created before schema migrations), the same hook should be able to allow me to do more invasive prodding with MSSQL's schema tables. [1] sp_rename - http://technet.microsoft.com/en-us/library/ms188351.aspx [2] ALTER TABLE - http://msdn.microsoft.com/en-us/library/ms190273.aspx Regards, Michael Manfre -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAGdCwBt3myq%3D9%2BYTtsuJmYOs0S%2BJ6fSQxFxK_Ci6yYDaw%3DR_Gw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: SchemaEditor Enhancements
Trunk is still open for all 1.7 changes; 1.7 alpha is currently planned for mid January, which is the cutoff point for major API changes; the beta a month or so after that, which is the final cutoff for minor API changes. On top of that - it looks like you're proposing a modification to the schema migration API - that means you're not proposing a new feature, but pointing out a bug/limitation in a feature that has been added for 1.7. That means the window is definitely open, because the original feature is already there. So yes - if you want to propose an API change for 1.7, you've still got time. Yours, Russ Magee %-) On Fri, Dec 20, 2013 at 3:17 PM, Michael Manfre wrote: > I just started to work on Django 1.7 support for django-mssql and I don't > remember if it's too far along to get API changes in for the schema editor? > I've hit a few road blocks with the current implementation of > BaseSchemaEditor. I've only just started to get up to speed with the new > changes, so please bear with me. What the API seems to be lacking, at least > for my needs right now, is more hooks to execute the proper SQL. > > There exists an alter_db_table method that acts as a shim for > sql_rename_table, but such a hook doesn't exist for sql_rename_column. I > need both of these because MSSQL uses a stored procedure to rename objects > [1], which needs the table and column names to be strings that haven't > passed through quote_name(). > > The second API issue I've run in to is that MSSQL's equivalent to DROP > DEFAULT (sql_alter_column_no_default) is to drop a named constraint. To be > able to do this, I need to be able to define the column's DEFAULT as a > named constraint (sql_alter_column_default). If the hooked method for these > were provided with the model and column name, that seems like it would be > sufficient for me to be able to generate a consistent, unique constraint > name for both of those. > > The above would work when the default constraint was named. If its name is > not known (e.g. random constraint name for columns created before schema > migrations), the same hook should be able to allow me to do more invasive > prodding with MSSQL's schema tables. > > [1] sp_rename - http://technet.microsoft.com/en-us/library/ms188351.aspx > [2] ALTER TABLE - http://msdn.microsoft.com/en-us/library/ms190273.aspx > > Regards, > Michael Manfre > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" 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 http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAGdCwBt3myq%3D9%2BYTtsuJmYOs0S%2BJ6fSQxFxK_Ci6yYDaw%3DR_Gw%40mail.gmail.com > . > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84-q-eMMxOR58Bh2SvGjztdNawcO%3DfsRDvXvikG7ot7iAQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
