Re: Faster numbers for Oracle

So,... On Monday 17 June 2013 16:02:05 Shai Berger wrote: > On Thursday 16 May 2013 03:51:05 Shai Berger wrote: > > Ticket #20414[0] and PR #1071[1]. > > Over a month, and no comment from anyone on these; I take it as sign that > nobody has time for it. Unless someone wakes u

Re: MAC adddres field

On Wednesday 26 June 2013, Patryk Ściborek wrote: > W dniu środa, 26 czerwca 2013 17:26:12 UTC+2 użytkownik Carl Meyer napisał: > > Do you have any new information to justify why the existing resolution > > of #2239 should be reconsidered? > > > > I think the existing resolution is correct. This s

Re: Reconsider 20383: limited contexts for makemessages

On Thursday 04 July 2013 12:40:29 Benjamin Wohlwend wrote: > As it happens, ticket #20383 would > provide the perfect solution for this, even if the use case therein is > different. I guess Claude was right in his assertion that the white > labeling use case might be to limited to warrant the addit

Tests -- Errors vs. Failures

Hi all, I just pushed a fix to a test failure on Oracle -- the last-executed-query test. However, I want to ask about the preferred style in writing the test itself. The test, as it is written now, is: def test_last_executed_query(self): """ last_executed_query should not ra

Oracle users -- which first, Python 3 or Oracle 12?

Hi Oracle users, As you may be aware, Oracle 12 was released last month, and Django 1.6 declares Python 3 fully supported. As you may also be aware, Django currently cannot be tested with Oracle 12 [1] or with earlier Oracle under Python 3 [2], so these two must be declared unsupported for the

Re: Proposal: make Model __unicode__() default to self.name

On Thursday 11 July 2013 17:57:34 Aymeric Augustin wrote: > 2013/7/11 mjl Martin J. Laubach > > > Perhaps to have it a tiny little bit more useful, have it default to > > "MyModel object (object_pk)" ? > > I could support that. object_pk will be None when the object isn't saved > yet, but that's

Re: Custom Chainable QuerySets (#20625)

On Monday 22 July 2013 13:25:38 Anssi Kääriäinen wrote: > On Monday, July 22, 2013 1:16:04 PM UTC+3, Loic Bistuer wrote: > > On Jul 22, 2013, at 4:38 PM, Chris Wilson > > > > > > > wrote: > > > I think that's very true. How about this? > > > > > >> class MyQuerySet(models.QuerySet): > > >>

Re: [GSoC] Revamping validation framework and merging django-secure once again

Hi Christopher, While you're dealing with model validation, I wonder if you can take a look at this little example -- a minor failure in the current model validation: class General(models.Model): name = models.CharField(max_length=30) class Special(General): pass cl

Re: [GSoC] Revamping validation framework and merging django-secure once again

On Thursday 25 July 2013 08:37:06 Russell Keith-Magee wrote: > > Could I get you to open this as a ticket so that it isn't forgotten? > https://code.djangoproject.com/ticket/20814 Thanks, Shai. -- You received this message because you are subscribed to the Google Groups "Django develo

Proposal: Modifying the CSRF protection scheme

Hi everybody, TL;DR: A simple change can make Django's CSRF protection a little better; an additional, slightly less simple one, can also make it look better. Django's CSRF protection scheme is a bit unusual; unlike most such schemes, it does not rely on a value stored in the server that needs

Re: Proposal: Modifying the CSRF protection scheme

Hi (quotation below edited) On Monday 29 July 2013 17:59:53 Matthew Lauber wrote: > On Sat, Jul 27, 2013 at 7:12 PM, Shai Berger wrote: > > > > a) Use a signed cookie for csrftoken -- using Django's existing signing > > facility[4], this means signing the cookie wi

Re: Proposal: Modifying the CSRF protection scheme

Hi, On Sunday 04 August 2013 01:26:58 Luke Plant wrote: > On 28/07/13 00:12, Shai Berger wrote: > > > > a) Use a signed cookie for csrftoken -- using Django's existing signing > > facility[4], this means signing the cookie with the SECRET_KEY from the > > settings

Re: Proposal: Modifying the CSRF protection scheme

Hi, You can find my work-in-progress at https://github.com/django/django/pull/1454. It is nowhere near ready yet -- it is still missing some pieces and has commented-out debug printing, but I'm done for tonight, and I think it is advanced enough that people may want to take a look and comment. O

Re: Proposal: Modifying the CSRF protection scheme

On Friday 09 August 2013 18:08:26 Luke Plant wrote: > On 03/08/13 23:57, Shai Berger wrote: > > This would work exactly like it works today, except with signed cookies. > > That is, the "user specific element" is the cookie. CSRF is about > > tricking the user int

Re: Order of INSTALLED_APPS

On Monday 02 September 2013 12:34:03 VernonCole wrote: > It also affects _how_ South works, not just _whether_ it works. Only this > week I had to install a patch for the formhub package which consisted of > re-ordering INSTALLED_APPS so that tables were built in the correct order > on PostgreSQL

Re: Is "transaction.atomic" in 1.6 supposed to work this way?

On Sunday 22 September 2013 10:38:32 Anssi Kääriäinen wrote: > > I would go for an approach where all queries in marked-for-rollback block > are prevented. See https://github.com/akaariai/django/compare/ticket_21134 > > Note that this is the test case I am complaining about: > > r1 = Reporter.ob

Re: Is "transaction.atomic" in 1.6 supposed to work this way?

On Sunday 22 September 2013 12:59:02 Florian Apolloner wrote: > On Sunday, September 22, 2013 8:38:10 PM UTC+2, Shai Berger wrote: > > I would take Anssi's suggestion another step forward -- or backward, > > depends > > where you're looking from :-) -- stop ma

Re: Is "transaction.atomic" in 1.6 supposed to work this way?

On Sunday 22 September 2013 22:55:15 Aymeric Augustin wrote: > Hi Michael, > > On 22 sept. 2013, at 22:48, Michael Manfre wrote: > > On Sun, Sep 22, 2013 at 3:18 PM, Aymeric Augustin > > wrote: > > > > The extra queries for the savepoints will break all tests that use > > assertNumQueries — wel

Re: Django 1.6 and migrating to the new test runner: note on user experience

On Friday 27 September 2013 20:01:00 Carl Meyer wrote: > > 1) The status quo. If people run the new "manage.py check" command, > they'll get a warning directing them to the release notes. But given > that "manage.py check" is new, its unlikely anyone would run it unless > they've already read the

Re: Error recovery in transactions

On Saturday 28 September 2013 09:35:06 Aymeric Augustin wrote: > Hello, > > This is a follow-up to « Is "transaction.atomic" in 1.6 supposed to work > this way? ». Two options seem viable to me. We must chose one before > releasing 1.6 RC1. > > Other options have been proposed but I couldn't make

Re: Error recovery in transactions

On Saturday 28 September 2013 12:24:22 Aymeric Augustin wrote: > On 28 sept. 2013, at 11:56, Shai Berger wrote: > > > If Option 2 is to be viable, it needs to be modified to store the original > > problem and its traceback, and add them to the errors somehow. On Python &g

Oracle broken on 1.6

Hi, It looks like the fix to #21165[1] broke the tests on Oracle (seems like the behavior with respect to timezone information changed) in 1.6.X. I just saw the Jenkins report[2], I hope to look at it later tonight. Thanks, Shai. [1]https://github.com/django/django/commit/5252885494079

Re: Oracle broken on 1.6

Hi, On Friday 04 October 2013 19:39:51 Ramiro Morales wrote: > > On Fri, Oct 4, 2013 at 12:43 PM, Shai Berger wrote: > > Hi, > > > > It looks like the fix to #21165[1] broke the tests on Oracle (seems like > > the behavior with respect to timezone information cha

Re: runserver ignoring SCRIPT_NAME?

Hi JK, On Thursday 10 October 2013 15:16:41 JK Laiho wrote: > > I'm developing a Django site that will be served in production by > nginx-proxied gunicorn. The site is mounted on a subpath, and the nginx > config sets SCRIPT_NAME to /path to facilitate this. > > This arrangement works fine with

Re: #18659 -- Deprecating request.REQUEST

On Wednesday 16 October 2013 15:52:56 John Paulett wrote: > I'll chime in with a counterpoint. > > request.REQUEST can be helpful in limited cases when the server application > simply does not care whether it is receiving data via a GET query string or > x-www-form-urlencoded POST and a different

Re: #18659 -- Deprecating request.REQUEST

On Wednesday 16 October 2013 19:48:09 Aymeric Augustin wrote: > 2013/10/16 Javier Guerra Giraldez > > > yes, they're different, but is there any value in emphasizing the > > difference? > > The main value lies in emphasizing the difference between HTTP GET and HTTP > POST. That difference has se

Re: Feature request: New middleware method for "universal" decoration

On Tuesday 15 October 2013 11:49:32 Anssi Kääriäinen wrote: > On Tuesday, October 15, 2013 8:23:38 AM UTC+3, gavi...@gmail.com wrote: > > This topic was also discussed during the deprecation of > > TransactionMiddleware and the introduction of ATOMIC_REQUESTS. The > > existing middleware semantics

Re: Possible idea for removing global state in Django.

On Thursday 17 October 2013 08:34:48 Aymeric Augustin wrote: > > For instance, thread locals are strictly equivalent to regular variables in > tests because they are single threaded (with a handful of exceptions). But > allowing testing in isolation is a major goal of "removing global state". If

Re: #16245: send_robust should include traceback in response when Exception occurs

On Wednesday 30 October 2013 11:23:07 unai wrote: > > Now, this ticket doubts between two possible solutions. The first of them > is returning a `(receiver, (type, exception, traceback))` made by > `(receiver, sys.exc_info())` tuple if `exc_info` is True: > > for receiver, (typ, exc, tbk) in

Re: Why not use @classmethod decorator consitently in django/utils/functional.py?

Hi Adam, (reordering quoted parts a little) On Tuesday 19 November 2013 18:33:01 Adam Smith wrote: > Hi, I'm quite new to Python and Django Welcome aboard! > Like I said, I'm quite new to Python and this community, I'm not sure > whether this is the right place to ask this kind of question. >

Re: Related manager remove() and clear() methods - backwards incompatible changes

Hi, On Saturday 16 November 2013 21:02:00 Anssi Kääriäinen wrote: > Any feedback for pre/post_update idea? > As Loic said, the signals sound like they can be useful in a variety of situations. A couple of notes, though: > pre_update listeners get a queryset that isn't executed. The "query" par

Re: ManyToMany relationship can't be saved

On Friday 22 November 2013 07:31:38 Adam Smith wrote: > As I was learning the Django Docs ( > https://docs.djangoproject.com/en/1.6/topics/db/models/#extra-fields-on-man > y-to-many-relationships), I found the following code not working. Is it a > bug? At least the result is unexpected. > > ringo

Re: Self-referenced template recursion handling

On Monday 09 December 2013 14:58:34 unai wrote: > > > 2. This solution will complicate the template development. e.g. if a > > > > application overwrite the "admin/change_form.html" template and a > > developer wants to update this template, he will have to search this > > template in every app

Re: Enable longer wait in StoppableWSGIServer.shutdown / hardcoded parameter

Hi, On Monday 09 December 2013 17:52:20 James Pic wrote: > Hi all, > > I found that there was a hard coded 2 seconds limit in > StoppableWSGIServer.shutdown: > https://github.com/django/django/blob/1.6/django/test/testcases.py#L999 > > This causes problems on slow boxes ie. travis: > https://tra

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 answe

Re: Renaming apps.has_app

On Sunday 05 January 2014 22:47:22 Aymeric Augustin wrote: > On 5 janv. 2014, at 22:27, Josh Smeaton wrote: > > The only thing I have against it is that it may sound like it can take an > > iterable of app names, where has_app() does not have that problem. > What about is_installed? I'd go for __

Re: Renaming apps.has_app

On Sunday 05 January 2014 23:26:12 Aymeric Augustin wrote: > On 5 janv. 2014, at 22:54, Shai Berger wrote: > > I'd go for __contains__: > > if "django.contrib.auth" in apps: > I considered this one but I didn’t select it because it will restrict our > free

Re: django_bash_completion in Pypi Package

Hi Brett, On Monday 06 January 2014 08:57:50 Brett Nekolny wrote: > > I can't seem to get to django_bash_completion from a pypi package install > You don't really need one. django-bash-completion has had one significant change in almost four years. To find the completions, it invokes your "wor

Re: Forbidding double imports

On Sunday 05 January 2014 00:24:16 Florian Apolloner wrote: > Kill double imports with fire :þ (and now) +1 -- 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

Re: Migrations and swappable models/AUTH_USER_MODEL

On Wednesday 08 January 2014 18:04:44 Andrew Godwin wrote: > > There are a couple of potential approaches here: > > 1) Introduce a new value that can be used as a "to" parameter on > ForeignKeys which resolves to a swapped model in its internal > string-to-model converter. I'm thinking something

Re: Migrations and swappable models/AUTH_USER_MODEL

On Wednesday 08 January 2014 20:00:25 Andrew Godwin wrote: > > Instinctively, I'm almost -1 on 2); I'm not too happy about 1) either. If > > a model says it has a FK to auth.User, that shouldn't mean anything > > other than > > auth.User. I don't see that as cleanliness -- it's effectively > > monk

Re: Migrations and swappable models/AUTH_USER_MODEL

On Saturday 11 January 2014 11:45:55 Andrew Godwin wrote: > OK, I like that approach Russ - an inverted 1b. It'll be a bit harder to > explain in the docs, but it won't catch anyone out unawares, which is the > key thing. > I like it too. And foot-in-mouth re referencing swappables notwithstandin

Re: Migrations and swappable models/AUTH_USER_MODEL

On Thursday 09 January 2014 01:10:09 Raphaël Barrois wrote: > On Wed, 8 Jan 2014 20:27:54 +0200 > > Shai Berger wrote: > > as people already use auth.get_user_model() -- so, you can > > monkeypatch *that* when generating migrations, and let them just keep > &g

Testing parameters in database settings

Hi all, Django's database settings currently support eleven separate parameters for testing, all named 'TEST_*', most of them more-or-less backend-specific (in fact, six -- already a majority -- are Oracle-specific). We have now discovered[1] that we need even more Oracle-test-specific paramete

Re: permit global change of BaseForm.label_suffix

On Saturday 11 January 2014 19:34:42 Tilman Koschnick wrote: > Hi, > > I'd like to bring up #18133 again, which has been closed as wontfix. > > I am looking for an easy and non-intrusive way to override the default > colon suffix on form field labels. The suggested methods of subclassing > the af

Re: Testing parameters in database settings

Hi, On Tuesday 14 January 2014 21:35:04 Michael Manfre wrote: > Why are we not encouraging people to define different aliases for testing? > Many of those TEST_ settings could be given meaning to the database > configuration without being specific to running tests. Several of those > TEST_ settin

Re: Ticket #21751 review requested

On Friday 17 January 2014 01:19:29 Michael Manfre wrote: > In an effort to make Django a bit more explicit with regards to closing > cursors when they are no longer needed, I have created ticket #21751 [1] > with a pull request[2]. > > Most of the changes are straight forward and change the usage

Re: Ticket #21751 review requested

On Sunday 19 January 2014 11:52:40 Łukasz Rekucki wrote: > On 19 January 2014 09:12, Shai Berger wrote: > > On Friday 17 January 2014 01:19:29 Michael Manfre wrote: > >> In an effort to make Django a bit more explicit with regards to closing > >> cursors when they a

Re: Ticket #21751 review requested

On Sunday 19 January 2014 10:44:32 Michael Manfre wrote: > On Sun, Jan 19, 2014 at 5:23 AM, Shai Berger wrote: > > Still, spreading with-blocks all over the code for this looks very ugly to > > me. > > I'd rather add an execute_single() or execute_and_close() method

Re: Testing parameters in database settings

On Wednesday 15 January 2014 00:02:52 Michael Manfre wrote: > On Tue, Jan 14, 2014 at 3:26 PM, Shai Berger wrote: > > > > Your suggestion, if I understand it correctly, gives the user two options: > > > > 1) Use separate credentials, and perhaps even a separate service

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On Tuesday 21 January 2014 20:03:25 Carl Meyer wrote: > On 01/21/2014 06:48 AM, Russell Keith-Magee wrote: > > As Marc indicated in his post, I don't think we should be treating this > > as a permanent feature of the API, but as but as a migration aid. Yes, > > default_app_config will exist as a ba

Re: Must a Django Database Support Migrations?

Hi, (quotations reordered a little) On Wednesday 22 January 2014 14:48:25 Russell Keith-Magee wrote: > On Wed, Jan 22, 2014 at 1:51 PM, Michael Manfre wrote: > > *Why Disable Migrations?* > > > > 1) Not all projects need schema migrations or want Django to manage the > > migrations. My primary

Re: Must a Django Database Support Migrations?

On Wednesday 22 January 2014 16:26:50 Russell Keith-Magee wrote: > On Wed, Jan 22, 2014 at 3:59 PM, Shai Berger wrote: > > > > B) Allow the test suite to run on an existing schema. The Oracle backend > > already does this (badly) -- its six specific TEST_* parameters are >

Re: Enforce the use of a unicode string in settings.LANGUAGES

On Wednesday 22 January 2014 15:59:23 Henrique Romano wrote: > On Wed, Jan 22, 2014 at 11:38 AM, gilberto dos santos alves < > > gsa...@gmail.com> wrote: > > please look details about on [1]. if you put > > > > # -*- coding: utf-8 -*- on sources and config files for django your > > string "portu

Re: Enforce the use of a unicode string in settings.LANGUAGES

On Wednesday 22 January 2014 18:01:14 Henrique Romano wrote: > On Wed, Jan 22, 2014 at 12:39 PM, Shai Berger wrote: > > This has nothing to do with the LANGUAGES setting, or the string being a > > language name. it just so happens that ugettext tries to return unicode, > &

Re: Enforce the use of a unicode string in settings.LANGUAGES

On Wednesday 22 January 2014 18:29:18 Henrique Romano wrote: > On Wed, Jan 22, 2014 at 2:16 PM, Shai Berger wrote: > > Wait -- so the real context (which, as Ramiro noted, you left out) is > > > > # settings.py > > > > LANGUAGES = (('pt_BR',

Re: Enforce the use of a unicode string in settings.LANGUAGES

On Wednesday 22 January 2014 18:58:26 Henrique Romano wrote: > On Wed, Jan 22, 2014 at 2:38 PM, Shai Berger wrote: > > I don't think Django should take responsibility for a 3rd-party package > > which > > decides that some part of a setting should be translatable wheth

Re: Must a Django Database Support Migrations?

On Wednesday 22 January 2014 19:15:08 Michael Manfre wrote: > > I think we all agree that any database backend must continue to be able to > create or delete schema objects, or provide something like Oracle's > TEST_CREATE setting to allow that to be done as a non-Django step. Actually, I don't;

django.core.checks.register shouldn't be (primarily) a decorator

Hi, I took a look at PR 2192[1] earlier, and noted that checks.register keeps being used as a function, called from AppConfig.ready(), and not as a decorator; but it is defined as a decorator, so it looks a little funny: checks.register('models')(check_generic_foreign_keys) (from the c

Re: Ticket #21751 review requested

is a standard pattern and > allows Django to follow PEP 249 without extra modifications. > > The overall feedback I've gotten from my pull request seems positive. I'll > rebase it against master and submit it for merging. > > Regards, > Michael Manfre > > O

freenode under DDOS attack -- IRC works on webchat

If you're experiencing difficulties connecting to IRC, it's not your fault; the #freenode channel's subject is currently: """ We're currently experiencing what appears to be a DOS attack against our servers. Some servers are offline, and local IPs appear in the rotation, meaning that some conn

Re: test_disable_constraint_checks_context_manager

On Sunday 02 February 2014 23:08:05 Wlodek wrote: > Hi all, > > I have doubt about mentioned test. Is it correct? > The test is correct for the backends in core. > As context manager "constraint_checks_disabled" enables > constraint checking upon exit which is before end of transaction (rollbac

Re: Gsoc project idea

Hello Navneet, On Monday 17 February 2014 17:49:36 NAVNEET SUMAN wrote: > I would like to work on the Improving the less popular backends supported > by django for this GSOC . What are the various backend u would like to see > in django/ or what are the issues related with less popular backends T

Re: Issue with save/save_model/clean from admin (django 1.6.3dev)

Hi Stefano, You are leaving out important details -- the error you are getting is clearly about a "related field" (ForeignKey, OneToOne or ManyToMany), but there is no such field in the model you provided. I suspect it is more likely to be a usage issue rather than a problem in Django code or

Re: The model API and strong typing

On Saturday 01 March 2014 19:07:08 Aymeric Augustin wrote: > On 1 mars 2014, at 09:14, Martin Matusiak wrote: > > Now in the case of sqlite, which is very permissive, it will happily > > accept values like 1 and {} and store them as "1" and "{}" (wtf) > > respectively. So if I'm running my tests a

Re: The model API and strong typing

On Sunday 02 March 2014 10:24:13 Aymeric Augustin wrote: > On 2 mars 2014, at 08:49, Shai Berger wrote: > > On Saturday 01 March 2014 19:07:08 Aymeric Augustin wrote: > >> You should never, ever, for any reason, use a different database in > >> development, test and

Re: requiring login to perform Trac actions?

On Monday 03 March 2014 16:17:13 Tim Graham wrote: > There's been some discussion on ticket > #22067 and #django-dev about > requiring Trac login to help cut down on spam and generally improve the > quality of the discussion. > +1 for requiring login,

Re: Testing parameters in database settings

Hi, I've put up https://github.com/django/django/pull/2400 for review. It makes the changes discussed -- test settings go into a 'TEST' dictionary in the database settings, with a deprecation warning for old settings. While at it, I added (in a separate commit) a renaming of two Oracle-specific

Re: Testing parameters in database settings

; database (due to the datafile size). Similarly, the test runner can not > create the database for Oracle RAC because of the datafile name. > > Regards, > > Josh > > On Thursday, 6 March 2014 06:41:57 UTC+11, Shai Berger wrote: > > Hi, > > > > I'v

Re: DRY date_format and datetime objects

Hi, On Thursday 06 March 2014 23:23:50 Jon Dufresne wrote: > > I am using Django 1.6. I find myself using date_format semi-regularly > to convert datetime objects to strings in the DATE_FORMAT format. [...] > I am considering a pull request that extends Python's datetime class > that overrides th

Re: Case handling for application verbose names

On Monday 10 March 2014 08:30:41 Russell Keith-Magee wrote: > On Mon, Mar 10, 2014 at 4:23 AM, Aymeric Augustin < > > aymeric.augus...@polytechnique.org> wrote: > > > > I'm now thinking that it's acceptable to keep capitalized application > > names and live with the inconsistency. However, if I h

Re: [GSoC] Dynamic, rule-based ModelForms

On Thursday 06 March 2014 01:17:51 Paolo Coffetti wrote: > Hi Django devs, > > I want to share an idea with you and get some feedback in order to know if > it makes sense, if it could solve a common problem and maybe evolve into an > official GSoC proposal. > > Some years ago I was working on a p

Re: Add support for get_or_none?

On Thursday 13 March 2014 18:45:31 Cal Leeming [Simplicity Media Ltd] wrote: > Seems this issue was brought up several years ago, though the thread was > later hijacked for other functionality and get_or_none fizzled out. > https://groups.google.com/forum/#!topic/django-developers/Saa5nbzqQ2Q > >

Re: Add support for get_or_none?

On Thursday 13 March 2014 14:34:18 Josh Smeaton wrote: > +1 on get_or_none. It seems to be a pattern that comes up quite a lot in > user code, and I know I've had use for it lots of times. Since 1.6, you should just be using first(). Compared to the try-get-except-DoesNotExist-return-None patter

Re: Add support for get_or_none?

There is a family of names that would be valid -- names that cannot be used to name fields -- and that is names that begin with dunder. I would like to see neither get(__default=x) nor first(__only=True) -- I think that's quite ugly -- I just want to remind us that technically, the option exist

Re: APPEND_SLASH skip per URL or per base_uri

On Friday 14 March 2014 17:07:41 Val Neekman wrote: > Hi Aymeric, > > Localized solution is fine, but when I saw the number posts from people who > were trying to find a solution to this, I thought, perhaps it would be a > nice little enhancement to the APPEND_SLASH functionality. > https://gith

Re: Migrations in Django 1.7 make unit testing models harder

On Tuesday 25 March 2014 20:36:39 Marc Tamlyn wrote: > Do we have an equivalent of south's --update? This would mean you don't get > many files. We don't want to make it too hard for people to work in a > strict TDD fashion. > +1 Shai. -- You received this message because you are subscribed to

Re: Proposal for prepared statements API

On IRC, @apollo13 asked some very good questions about the lifecycle of prepared statements. I would like to elaborate. Prepared statements usually live on the server, in the context of a session -- which, for Django, means they're only valid in the thread where they were built; without persis

Trac #22343 -- select-for-update in autocommit mode

Hi, Ticket #22343[1] is about a couple of tests failing under Oracle. But it raises a question that's a little deeper. The relevant tests do a select-for-update to verify that the "for update" clause is, indeed, added; and they happen to run in autocommit mode. They fail because, under Oracle,

Re: Migrations in Django 1.7 make unit testing models harder

On Thursday 27 March 2014 01:39:53 Bernie Sumption wrote: > > I'd be willing to keep the current contract of "things without a > > migrations directory don't get migrated", but I suspect you're doing > > things > > on apps that already have migrations (which makes my reticence to add a > > setting

Re: Add support for get_or_none?

Hi, (the below is reordered) On Wednesday 26 March 2014 21:44:22 Anssi Kääriäinen wrote: > > Actually I think we could use .get(default=None). The way to do this is: > 1. Deprecate direct use of .get(default=lookup_value), instead ask users > to do .get(Q(default=lookup_value)). > 2. After d

Re: LiveServerTestCase vs StaticLiveServerCase

On Saturday 29 March 2014 19:11:17 Harry Percival wrote: > > What I *am* saying is that, in my opinion, there's not much point in > LiveServerTestCase if it doesn't do static files. So, to keep things > simple, it would be simpler to remove it, and just have on LiveServer test > class, that lives

Re: Migrations in Django 1.7 make unit testing models harder

On Sunday 30 March 2014 15:08:17 Harry Percival wrote: > Ah, so the reason I was confused is because it *looks* like the default is > the empty string, because that's what you get if you initialise an object, > by default. But at the database level, the default for the column is NULL. > Is that rig

Re: Trac #22343 -- select-for-update in autocommit mode

On Thursday 27 March 2014 19:59:52 Aymeric Augustin wrote: > On 27 mars 2014, at 15:20, Shai Berger wrote: > > So I'm suggesting we change the behavior of select-for-update queries, to > > error out when executed with no transaction. This is a > > backwards-incom

Re: Trac #22343 -- select-for-update in autocommit mode

On Monday 31 March 2014 09:18:57 Anssi Kääriäinen wrote: > On 03/30/2014 07:48 PM, Shai Berger wrote: > > While fixing this, I ran into this line in the current docs: > > """ > > Using select_for_update on backends which do not support SELECT ... FOR > > U

Re: Unicode in validators tests

On Wednesday 02 April 2014 13:43:23 alois.guill...@gmail.com wrote: > Hi, > > I was wondering if the test inputs in the validators tests should be given > as unicode or python string. It seems to me that at the moment the > validation is done, the string is already coded in unicode. However the >

Re: Should there be a "is" comperator: {% if A is B %}?

Hi all, For the use case brought up originally, note https://code.djangoproject.com/ticket/20684 In that spirit, I think the better solution for the more general case brought here is a filter, say tag_attr, which takes a name and a value and renders them appropriately: {% for name, value in a

Re: Trac #22343 -- select-for-update in autocommit mode

Hi Marti, On Tuesday 22 April 2014 18:37:37 Marti Raudsepp wrote: > On Thu, Mar 27, 2014 at 4:20 PM, Shai Berger wrote: > > The relevant tests do a select-for-update to verify that the "for update" > > clause is, indeed, added; and they happen to run in autocommit mo

Timeline for 1.4.12/1.5.7/1.6.4

Hi, Since 1.4.11/1.5.6/1.6.3 introduced the reverse regression, and it was fixed already -- are we planning another release soon? Thanks, Shai. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and st

Re: Database-dependant tests and third-party backends

Hi, On Wednesday 07 May 2014 19:40:08 Aymeric Augustin wrote: > > I'm trying to make the lives of maintainers of third-party database > backends a bit easier. > +1. > > *1) Checking database features* > > This is the correct solution for database-dependant tests in general. > In most cases

Re: Why not Single Table Inheritance?

On Monday 12 May 2014 12:27:01 Thomas Güttler wrote: > Single Table Inheritance is used by ruby-on-rails and SQLAlchemy. > > Are there reasons why it is used in django? > Essentially, STI is a form of database denormalization. I think Django should not encourage this. > I would love to see a p

Re: Schema tests and .extra queryset method

Hi Maximiliano, The issue of case in quoted and un-quoted names in SQL is indeed a sad mess, bad decisions made in the 1960s that we still need to live with today. On Wednesday 21 May 2014 15:38:57 Maximiliano Robaina wrote: > > self.assertEqual(Author.objects.extra(where=["thing = 1"]).count()

Re: Why not Single Table Inheritance?

On Thursday 22 May 2014 11:05:24 Anssi Kääriäinen wrote: > I think it is time to add a new model classmethod from_db() to Django. > > The idea is to allow customization of object initialization when loading > from database. Instead of calling directly model.__init__ from the queryset > iterators,

Fwd: [cx-oracle-users] cx_Oracle 5.1.3

Hi all, This release of cx_Oracle includes fixes the segfaults encountered with Python3, and includes significant performance improvements for 64-bit platforms (where long is 64-bits, so, specifically, Windows not included). Strongly recommended for all Oracle users. Have fun, Shai. -

Re: Schema tests and .extra queryset method

Hi Maximiliano, Sorry for the delay in responding to this. On Thursday 22 May 2014 17:06:23 Maximiliano Robaina wrote: > El jueves, 22 de mayo de 2014 03:24:12 UTC-3, Shai Berger escribió: > > > > Quoting it uncoditionally would break the test on Oracle (which, by > > d

django.utils.six.bytes_types?

Hi all, While solving #22715[1], I found myself writing these lines: elif (isinstance(value, six.memoryview) or six.PY3 and isinstance(value, bytes)): six.memoryview -- django.utils.six.memoryview, to be accurate, there's no memoryview in the original six

Re: Make url patterns group kwargs more simple

Hi Alexendr, On Wednesday 28 May 2014 18:54:05 Alexandr Shurigin wrote: > Hi all. > > What do you think about adding some extra default and more simpler syntax > for url patterns? > [looking for a way to re-write...] > > url(r'^(?P[^/]+)/(?P[^/]+)/news/(?P[^/]+)$',... > [...as...] > > > url(

Re: django.utils.six.bytes_types?

On Wednesday 28 May 2014 22:38:20 Aymeric Augustin wrote: > The name seems confusing to me: it's called bytes_type but its main purpose > is to exclude bytes on Python 2. Otherwise you'd just write > isinstance(value, (bytes, six.memoryview)). > I renamed it to "buffer_types" -- because English

Re: django.utils.six.bytes_types?

On Thursday 29 May 2014 12:04:59 Aymeric Augustin wrote: > > Le 28 mai 2014 à 23:57, Shai Berger a écrit : > > > > So, the PR can be merged without documentation ? > > Since it's a private helper, that's OK. Actually, it isn't: https://docs.djangopr

Re: Why not Single Table Inheritance?

Let me expand on Russell's expletives: On Friday 06 June 2014 09:42:15 Thomas Güttler wrote: > > I guess a lot of developers don't want to hear the next lines: > > I think it is a "not invented here" syndrome: Ruby on Rails did it before. > That's a reason to do it different. > This does deser

<    1   2   3   4   5   6   7   >