Caching back-refernces on one-to-one fields

Hi Django devs, I have a small improvement to suggest for one-to-one fields: Make them cache back-references on related objects. That is, assume class A(model): pass class B(model): a = OneToOneField(A) a1 = A.objects.get(...) # assume a1 has a related B record

Re: First-run experience w/ psycopg2 and django 1.3.x

On Thursday 19 January 2012, Jeremy Dunck wrote: > There's a known problem w/ latest pg (2.4.2) and we decided not to > backport the fix to 1.3.x because there's a workaround. > > https://code.djangoproject.com/ticket/16250 > > All well and good, but someone coming to Django w/ postgres will

Re: Caching back-refernces on one-to-one fields

Hi again, > > john = Author.objects.get(name='john') > books = list(john.book_set.all()) > > # Does a database query, but should be smart enough to simply return john. > books[0].author > """ > > I'm pretty sure there's a long-standing ticket for this, but I'm not > sure which one it is. Shai,

django.contrib.auth.models.get_hexdigest missing in 1.4

Hi, In the process of upgrading to Django 1.4, I've run into a little problem: one of our files uses django.contrib.auth.models.get_hexdigest, which is no longer present. I searched, and could find no mention of this in release notes, tickets, or the developers group. Was this, for some

Re: auth_permission column lengths

Hi all, On Tuesday, June 19, 2012 5:12:47 PM UTC+3, Florian Apolloner wrote: > > Hi Greg, > > Django itself can't change that currently since there is no support for > schema alteration in Core. Once we get that we can tackle issues like that > and increase to a sensible limit. (both name and

Django Oracle backend vs. numbers

Hi Django developers, I've been working with Oracle on a project with some performance requirements, and we've noticed long ago that the Django Oracle backend performs significantly worse than other backends; we've been able to profile it and see that, indeed, a lot of time is spent in

Re: Django Oracle backend vs. numbers

Hi Ian, Jacob, Anssi and all, Thanks for the quick and positive responses. On Wednesday 29 August 2012, Ian Kelly wrote: >https://github.com/ikelly/django/commit/086f502a1c2acb9db27531f7df78cb9df9ab83bd > > Shai, if you would be willing to try this patch, I'd like to hear your > results.

Re: Django Oracle backend vs. numbers

On Wednesday 29 August 2012 22:17:22 Ian Kelly wrote: > > https://github.com/ikelly/django/commit/086f502a1c2acb9db27531f7df78cb9df9a > b83bd > I've run a version based on this -- basically, porting the patch to Django 1.3 which we use (so, no tzinfo), using "float" as the default for

Re: Django Oracle backend vs. numbers

On Tuesday 04 September 2012, Ian Kelly wrote: > On Mon, Sep 3, 2012 at 6:14 AM, Shai Berger <s...@platonix.com> wrote: > > On Wednesday 29 August 2012 22:17:22 Ian Kelly wrote: > >> https://github.com/ikelly/django/commit/086f502a1c2acb9db27531f7df78cb9d > >&g

Re: Django Oracle backend vs. numbers

On Wednesday 05 September 2012, Ian Kelly wrote: > > Thanks for tracking that down. _rowfactory was a module-level > function rather than a method, and I should have left it that way. So -- Ian, Anssi, are you going to include the fix in Django 1.5? I can help by either reviewing it for you or

Re: Django Oracle backend vs. numbers

On Sunday 23 September 2012 15:05:21 Anssi Kääriäinen wrote: > > If you decide to work on this, please split the patch into two: one > for the ._rowfactory change, one for the feature addition. My belief > is that the ._rowfactory change is going to be something we can very > easily justify

Re: Django Oracle backend vs. numbers

On Sunday 23 September 2012, Anssi Kääriäinen wrote: > Doing final polish for Ian's patch and providing benchmark results for it > will get this patch closer to commit. > I had hoped the Django test suite alone will provide a convincing benchmark, but apparently that is not the case -- on my

Re: Django Oracle backend vs. numbers

On Tuesday 25 September 2012 10:03:11 Anssi Kääriäinen wrote: > > Am I correct the benchmark is basically: > > cursor = connection.cursor() > cursor.execute("some sql fetching many rows with NUMBER() columns") > timer.start() > for row in cursor.fetchall(): > pass > print timer.used() >

Re: Django Oracle backend vs. numbers

On Wednesday 26 September 2012 20:26:11 Andre Terra wrote: > On Mon, Sep 24, 2012 at 9:41 PM, Shai Berger <s...@platonix.com> wrote: > > While preparing the patch, I ran into the inspectdb regression test > > suite; this suite includes, among other things, a model with a data

Re: Django Oracle backend vs. numbers

On Tuesday 25 September 2012, Ian Kelly wrote: > On Tue, Sep 25, 2012 at 11:47 AM, Ian Kelly wrote: > > Thanks for putting together a pull request. Please note the patch > > will also need to update the documentation to state the new cx_Oracle > > version requirement (was

Re: Django Oracle backend vs. numbers

Hi all, On Sunday 23 September 2012 15:05:21 Anssi Kääriäinen wrote: > > Doing final polish for Ian's patch and providing benchmark results for it > will get this patch closer to commit. > I made some initial benchmarks, and they do not reflect the change I've seen in the actual application.

Re: Django Oracle backend vs. numbers

Hi, Sorry about the delay in writing this -- it was in my mind, but I forgot to let it out... On Sunday 23 September 2012, Anssi Kääriäinen wrote: > On 22 syys, 23:34, Shai Berger <s...@platonix.com> wrote: > > > > [...] I will also include the extra setting in > &g

Re: Django Oracle backend vs. numbers

Hi, and thanks for your attention. I know you must be extremely busy with other issues of the feature freeze. I just want to make some things clear: > Based on the above I am -1 on having a flag that interprets NUMBER > fields as floats. There is already an Oracle data type to use for > this. >

Re: Django Oracle backend vs. numbers

On Sunday 30 September 2012, Anssi Kääriäinen wrote: > > I walked into this one... But, sorry, I will not have time for this > pull request for 1.5. > Ok, I can't say you didn't warn me this would be the case. Thanks a lot for the time you did spend on it, Shai. -- You received this message

Re: Django Oracle backend vs. numbers

On Sunday 30 September 2012, Anssi Kääriäinen wrote: > > cur.execute("select case when dbms_random.random > 0.5 then 0.1 > else 0 end from testtable") > > Guess what is the type of the column? It is both Decimal and int, > alternating based on the random result. > > This seems like

Re: Update on localflavor move

On Saturday 13 October 2012, Tomas Ehrlich wrote: > Salut Claude, > > > I can work on this, however I'm wondering if it makes sense to re-add all > > translations in all packages. Is adding Korean translation to Switzerland > > localflavor useful? > > I think it is. If someone translated

Re: Django produce sql with table name different then specified in meta db_table

Hi Michal and Django devs, While for the most part, Jacob is correct in marking this as a usage question, there does appear to be something buggy here. Note how Michal is abusing the db_table setting to select a name with a schema. He's looking for "protein_therapeutics" (<30) in "mnowotka":

Re: #16779 - a tutorial for first time Django contributors

On Sunday 11 November 2012, Tim Graham wrote: > > I think the part that has the most potential to confuse new contributors is > the introduction of PYTHONPATH. Claude suggested we could simply instruct > users to run the tests like so: > > PYTHONPATH=/path/to/django ./run_tests.py

Re: Yet another __ne not equal discussion

On Friday 30 November 2012, Marek Brzóska wrote: > Has the matter been completely put away? > > I would like to bring it up again. > > I have Articles and Categories. An Article belongs to Categories: > > class Category(model): > pass > class Article(model): > category =

Oracle backend bug makes testing on oracle slower?

Hi all, I've just been hit by a very simple and annoying bug on Oracle, on Django 1.3.4. Without testing, it seems to no longer be as bad on master, but a shade of it still remains. The bug is this: The DatabaseFeatures for the Oracle backend do not specify that it supports transactions. On

Re: Oracle backend bug makes testing on oracle slower?

On Tuesday 11 December 2012, Ian Kelly wrote: > On Tue, Dec 11, 2012 at 6:31 AM, Shai Berger <s...@platonix.com> wrote: > > Hi all, > > > > I've just been hit by a very simple and annoying bug on Oracle, on Django > > 1.3.4. Without testing, it seems

Re: Oracle backend bug makes testing on oracle slower?

On Tuesday 11 December 2012, Florian Apolloner wrote: > On Tuesday, December 11, 2012 8:53:55 PM UTC+1, Shai Berger wrote: > > Should I open a ticket for it? It is a one-line patch... > > Please try to test this on master first, we most likely won't patch 1.3. > This

A regression that isn't a regression

Hi all, We've encountered a funny bug in our code, which I thought was worth sharing. I don't think a bug in Django is involved, but I suspect Django could do better to prevent it. The issue is with the distinct() method of querysets. Up to Django 1.3, it was documented as taking no

Re: A regression that isn't a regression

On Thursday 20 December 2012, Karen Tracey wrote: > This has come up before, see: https://code.djangoproject.com/ticket/17974 > Figures... > 1.3 is security-fix only at this point, Yes, and pretty close to not-even-security-fix; I'm well aware of that, and that's why I wrote: > > The issue

Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)

Hi, On Saturday 22 December 2012, Florian Apolloner wrote: > On Saturday, December 22, 2012 10:35:59 PM UTC+1, Ben Porter wrote: > > I would like to see support for relative paths. It seems the solution is > > simple, but I wonder if there is some compelling reason to require > > absolute paths?

Oracle testing issue, looks like bug: Separate connections to same DB

Hi all, I'm seeing a problem with testing on Oracle, in a setting where there are two defined databases that reference the same connection parameters (this is done to enable operations in two parallel, separate transactions); the 'other' database is not treated as a test database. This means

Re: Oracle testing issue, looks like bug: Separate connections to same DB

Hi Jani and all, On Thursday 27 December 2012 13:28:23 Jani Tiainen wrote: > 27.12.2012 13:08, Shai Berger kirjoitti: > > Hi all, > > > > I'm seeing a problem with testing on Oracle, in a setting where there are > > two defined databases that reference the

Re: Oracle testing issue, looks like bug: Separate connections to same DB

On Thursday 27 December 2012 15:11:31 Jani Tiainen wrote: > > TEST_MIRROR = 'default' means that instead of creating test database of > "auditlog" using independent database connection Django will reuse > connection to "default". That's how Django makes testing of replication > happen (that's

Re: Oracle testing issue, looks like bug: Separate connections to same DB

On Thursday 27 December 2012 15:16:15 Jani Tiainen wrote: > > Just out of curiosity - what's the rationale to duplicate connection > information? Why it's so important? As I noted before, the idea is to use the second connection to write things in a separate transaction. As the name 'auditlog'

Re: Oracle testing issue, looks like bug: Separate connections to same DB

Hi again, On Thursday 27 December 2012, Jani Tiainen wrote: > 27.12.2012 15:32, Shai Berger kirjoitti: > > On Thursday 27 December 2012 15:16:15 Jani Tiainen wrote: > >> Just out of curiosity - what's the rationale to duplicate connection > >> information? Why it's

Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)

On Saturday 29 December 2012, Cal Leeming [Simplicity Media Ltd] wrote: > Since the day I started using Django, I have always used a relative path > for TEMPLATES_DIR. > > import os > CURRENT_DIR = os.path.realpath(os.path.dirname(__file__)) > TEMPLATE_DIRS = "%s/templates/" % ( CURRENT_DIR, )

Re: Oracle testing bug (was Re: Oracle testing issue, looks like bug: Separate connections to same DB)

On Sunday 30 December 2012 21:54:52 Anssi Kääriäinen wrote: > > Seems like you are correct [...]. Please open a bug. > For anyone interested that isn't on the new-bugs list, it's https://code.djangoproject.com/ticket/19542 For anyone else: my apologies for the noise. Shai. -- You received

Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)

Hi, I have to take back my support of PROJECT_ROOT, in view of Aymeric's arguments. However, now I think he isn't pursuing the conclusions of the argument far enough: On Tuesday 01 January 2013, Aymeric Augustin wrote: > For instance, instead of using TEMPLATE_DIRS, project-wide templates can

Re: Minor feature: Make TestCase pass the testcase instance to self.client's constructor

On Friday 04 January 2013, Malcolm Box wrote: > > The general pattern I want to implement is have a test client that makes > assertions about all the requests made during a set of tests. For example, > it could check that every get() returned cache headers, or that > content_type is always

Re: Minor feature: Make TestCase pass the testcase instance to self.client's constructor

Hi again Malcolm, I think making assertions in the test client is wrong for most situations, though I can't (of course) say much about your specific case; so I'm -1 on adding the testcase as a client initializer argument (this would send the message that such things are encouraged). However,

Reminder: pending Oracle fixes and issues

Hi Django devs, and in particular Oracle users, This is to remind you of fixes I proposed for the Oracle backend, which were mostly discussed and accepted, but seem not to have made it into the codebase yet. I am referring to: - PR #393[0] - Includes two separate issues -- of which one has

Re: Oracle testing bug (was Re: Oracle testing issue, looks like bug: Separate connections to same DB)

On Thursday 03 January 2013, Jani Tiainen wrote: > 31.12.2012 14:18, Shai Berger kirjoitti: > > On Sunday 30 December 2012 21:54:52 Anssi Kääriäinen wrote: > >> Seems like you are correct [...]. Please open a bug. > > > > For anyone interested that isn't on the

Re: [SPAM] [New feature] What do you guys thinks about an automatizated ER model drawer?

Hi, On Friday 25 January 2013, Vitor Lima wrote: > > I was thinking in something like a feature to django-admin that will make > an automatic ER(entity-relationship) model of the entire database. I think > that this will help with documentation and with the projects that don't > have an ER

Re: Form.set_data method

On Thursday 31 January 2013, Byron Ruth wrote: > Here is the ticket: https://code.djangoproject.com/ticket/19668 and the > pull request https://github.com/django/django/pull/674 > > One user commented on the ticket raising a concern that it could possibly > be misused if the data is set after it

Re: cycle in nested loops

Hi, On Friday 01 February 2013, Aymeric Augustin wrote: > Hi Wim, > > Le 21 janv. 2013 à 18:01, Wim Feijen a écrit : > > Actually, the current behaviour is not to reset between loops. Is that > > intentional? > > Yes, this behavior is intentional. See Malcolm's comment (#4)

Re: Form validation - char field coerces *any* data into a unicode

On Saturday 09 February 2013, Yo-Yo Ma wrote: > A form that has a char field (e.g. "name") when provided a dict of data > will convert the value of "name" to a Unicode, no matter what. I understand > that this is desirable in some circumstances, but it can lead to things > > like: > >>>

Re: select_for_update running on db_for_read

Hi, On Monday 18 February 2013, Ioan Alexandru Cucu wrote: > > If I'm running a select_for_update statement in a multidb environment that > uses a read-only slave database > Why does this operation make sense? Why would you select-for-update if you don't intend to update? Or does updating on

Re: Database pooling vs. persistent connections

Hi, On Sunday 17 February 2013, Aymeric Augustin wrote: > **tl;dr** I believe that persistent database connections are a good idea. > Please prove me wrong :) > > [...] > > So -- did I miss something? I think you haven't -- but several points came to mind, which weren't discussed in this

Re: Is there a buildbot? Is there a waterfall? Do the tests pass against all backends?

On Sunday 17 February 2013, Florian Apolloner wrote: > Hi, > > you can see the tests at http://ci.djangoproject.com/ -- currently Oracle > is untested cause it's a major pita to setup on ubuntu. > The easiest way I know to set up Oracle on Debian/Ubuntu is to use Oracle's "Dev Days" VM

Re: [SPAM] Re: Is there a buildbot? Is there a waterfall? Do the tests pass against all backends?

On Sunday 24 February 2013, Florian Apolloner wrote: > > Yeah, I know about it and set it up on the CI during the sprints, it's > still segfaulting somewhere :/ > > http://ci.djangoproject.com/job/Django%20Oracle/database=oracle,python=pyth > on3.3/12/console > Mybe it's me -- I couldn't get to

Re: Is there a buildbot? Is there a waterfall? Do the tests pass against all backends?

On Monday 25 February 2013 13:41:10 Florian Apolloner wrote: > The problem is that it segfaults, when something like a segfault happens > you usually don't get more information than that... I tried to debug the > segfault but cx_Oracle or rather the instantclient stuff is installed > without debug

Re: [SPAM] Re: Is there a buildbot? Is there a waterfall? Do the tests pass against all backends?

Hi Florian, On Tuesday 26 February 2013, Florian Apolloner wrote: > On Monday, February 25, 2013 5:27:06 PM UTC+1, Shai Berger wrote: > > the tests were only attempted for Python3 > > versions. Did you try to set it up for Python2? > > No, since the Oracle tests are som

Re: Decision needed on formfield_callback

On Wednesday 27 February 2013, poswald wrote: > I'm wondering if we can open a quick discussion on the `formfield_callback` > method of django ModelForms.. > > The basic issue boils down to the fact that we have an undocumented (and > thus unsupported) method on ModelForm that would benefit

Re: [SPAM] Re: Is there a buildbot? Is there a waterfall? Do the tests pass against all backends?

Hi Florian, On Wednesday 27 February 2013, Florian Apolloner wrote: > Hi Shai, > > On Tuesday, February 26, 2013 2:18:14 AM UTC+1, Shai Berger wrote: > > > No, since the Oracle tests are somewhat slow we decided to just test > > > one Python for now. I will t

Re: first() and last(), earliest() and latest()

On Thursday 28 February 2013, Aymeric Augustin wrote: > > I would support renaming them to first / last through a deprecation path. > The new aliases would be available immediately, the old ones would be > removed in two versions. > +1 > And while we're there, I suggest to rely on the existing

Re: first() and last(), earliest() and latest()

Oopsie: On Thursday 28 February 2013, Shai Berger wrote: > > Note that with this suggestion: > > qset.filter(a=b).first(c) > > is not equivalent to > > qset.order_by(c).filter(a=b) > That should have read qset.order_by(c).first(a=b) Shai. --

Re: Switch to database-level autocommit

On Friday 01 March 2013, Aymeric Augustin wrote: > Hello, > > I'd like to improve transactions handling in Django. The first step is [to > replace -- assumed, SB] the current emulation of autocommit with > database-level autocommit. > There is an issue you seem to be ignoring: An "ORM Write"

Re: Switch to database-level autocommit

Thinking again, a few more points come to mind: On Friday 01 March 2013, Aymeric Augustin wrote: > > Such transactions are useless and don't come for free. Relying on them to > enforce integrity is extremely fragile — what if an external library > starts writing to a log table in the middle of

Re: Switch to database-level autocommit

On Saturday 02 March 2013, Aymeric Augustin wrote: > On 2 mars 2013, at 16:18, Shai Berger <s...@platonix.com> wrote: > > -1. Make it easier (and cross-backend) to set db-level-autocommit on. Put > > the setting for it in the default template for new projects. Don't > >

Re: Switch to database-level autocommit

Hi again, On Sunday 03 March 2013, Aymeric Augustin wrote: > On 2 mars 2013, at 21:46, Shai Berger <s...@platonix.com> wrote: > > The Django documentation on transactions, at the moment says this on > > Django's > > > > default behavior[0]: > >> Django

Re: Switch to database-level autocommit

Hi, Here's some thoughts on possible problems with Aymeric's plan. I like the look of the suggested transaction API, I'm raising these to help make sure it can be realized. On Sunday 03 March 2013, Aymeric Augustin wrote: > On 1 mars 2013, at 13:48, Aymeric Augustin >

Re: Switch to database-level autocommit

On Sunday 03 March 2013, Jacob Kaplan-Moss wrote: > Shai: do you have any real-world code that'd have data loss > with this bug? The code in sites I work on usually uses transaction middleware or @commit_on_success, so it would not suffer (nor benefit) from this change. So I tried to look for

Re: Switch to database-level autocommit

Hi, On Monday 04 March 2013, Aymeric Augustin wrote: > On 4 mars 2013, at 04:04, Shai Berger <s...@platonix.com> wrote: > > you need to be sure that, in all these places, either reads don't > > really affect consequent writes, or some constraint holds that is > > eq

Re: Switch to database-level autocommit

Hi Florian and everybody, On Sunday 03 March 2013, Florian Apolloner wrote: > On Sunday, March 3, 2013 12:27:47 AM UTC+1, Shai Berger wrote: > > > I also believe that it beats the alternative — namely, live with the > > > > > > current behavior fore

Re: Switch to database-level autocommit

On Tuesday 05 March 2013, Aymeric Augustin wrote: > On 5 mars 2013, at 01:50, Shai Berger <s...@platonix.com> wrote: > > I want to point out how ironic this whole issue turns out. > > That's a storm in a teapot. Let's keep some perspective: I really had no intentions of d

Re: Switch to database-level autocommit

On Tuesday 05 March 2013, Aymeric Augustin wrote: > On 5 mars 2013, at 12:50, Shai Berger <s...@platonix.com> wrote: > > At least the "delete duplicates" example I've pointed to shows, that it's > > quite easy to write code that is correct now, under the defaults

Re: Splicing Geometry by bounding box

On Monday 04 March 2013, John Baker wrote: > Hey I am currently working on a geolocation based game that utilizes a > geodjango application to manage querying, parsing, and server geographical > data to our client. We are currently using PostGIS to store our OSM data. > We are using the OSM

Re: Switch to database-level autocommit

On Tuesday 05 March 2013, Aymeric Augustin wrote: > > In practice, this would mean: > - Define "hook points" that are a superset the old and the new APIs. > - Re-implement the current transaction management with these "hook points" > (hard, because the intended behavior of the dirty flag isn't

Re: Moving database backends out of the core

Hi, On Tuesday 05 March 2013, Michael Manfre wrote: > Full disclosure, I maintain django-mssql and am biased toward having all > database backends treated as if they were 3rd party backends. > In recent years, I have been the main contributor to South's MSSQL and Oracle backends. I am biased

Re: Switch to database-level autocommit

Hi Ian, Aymeric and all, I stand corrected. On Tuesday 05 March 2013, Ian Kelly wrote: > On Tue, Mar 5, 2013 at 6:38 AM, Shai Berger <s...@platonix.com> wrote: > > > > When Django checks for a second record on get() it reads the second > > record, so a repeatable-rea

Re: Switch to database-level autocommit

On Wednesday 06 March 2013, Aymeric Augustin wrote: > > So part 3 of the plan is to replace TransactionMiddleware by something > based on transaction.atomic that actually works. For lack of a better > idea, I'm considering deprecating the middleware and replacing it with a > setting. This doesn't

Re: Test failures under Oracle

On Sunday 10 March 2013, Florian Apolloner wrote: > and provide help there… Eg: https://code.djangoproject.com/ticket/20014 is > a perfect example where someone with Oracle knowledge can chime in, Here's a starting point, a query for the constraints affecting a table, from the South backend for

Permissions model limiting the length of verbose-name

Hi all, I would like to draw your attention to bug #8162[1]. It is old as sin, and annoying as virtue. The gist of it is: because, for all models, when the admin is present, permissions are created automatically; because these permissions are named "Can %s %s" % (action, model.verbose_name);

Re: Permissions model limiting the length of verbose-name

Hi Russell, I'm reordering the text I'm replying to below, to make things clearer. On Monday 11 March 2013 12:14:22 Russell Keith-Magee wrote: > On Mon, Mar 11, 2013 at 5:58 PM, Shai Berger <s...@platonix.com> wrote: > > > > I would like to draw your attention to bug #8162

Re: Changes to django's settings module

Omer, To convince the core committers that the patch is valuable, you need to show how it improves things. Build examples for the use-cases mentioned in the thread, show how they would be done without your patch, and how the presence of your patch allows improvements. The main argument against

Re: Persistent connections, take 2

On Monday 18 March 2013 16:36:53 Aymeric Augustin wrote: > By default, the development server creates a new thread for each request it > handles. Not only does this negate the effect of persistent connections > (they're thread-local), > [...] > 1) Do we want to enable persistent connections in

Re: Is there a buildbot? Is there a waterfall? Do the tests pass against all backends?

Hi, Reviving an oldish thread: On Tuesday 26 February 2013 00:35:10 Florian Apolloner wrote: > it would be of great help > if you could setup cx_Oracle on an Ubuntu 11.10 (I have to double check > that tomorrow, don't have my ssh keys with me currently) 64 bit system with > python 3.3 and see if

Re: Persistent connections, take 2

On Monday 18 March 2013, Aymeric Augustin wrote: > On 18 mars 2013, at 17:10, Shai Berger <s...@platonix.com> wrote: > > If the persistent connections are thread-local, don't you want to close > > them anyway when the thread exits? > > Yes, do you know how this could b

Re: Is there a buildbot? Is there a waterfall? Do the tests pass against all backends?

On Monday 18 March 2013, Shai Berger wrote: > Hi, > > Reviving an oldish thread: > > On Tuesday 26 February 2013 00:35:10 Florian Apolloner wrote: > > it would be of great help > > if you could setup cx_Oracle on an Ubuntu 11.10 (I have to double check > > that

Re: Is there a buildbot? Is there a waterfall? Do the tests pass against all backends?

On Tuesday 19 March 2013, Florian Apolloner wrote: > Hi, > > On Tuesday, March 19, 2013 8:21:05 AM UTC+1, Shai Berger wrote: > > Is there any interest in fixing this, specifically? > > Sure, I just don't have to knowledge to debug cx_Oracle, so if you are up > to

Re: [SPAM] unittest2 discovery proposal

Hi, +1 in general. One concern, and one idea: > > -- Backwards-incompatible changes -- > > * Some valid test structures in Django don't work with unittest2. For > instance, tests in `tests/__init__.py` don't match a patter than > unittest would recognize if running discovery on a module. >

Re: Changing deferred model attribute behavior

On Friday 26 April 2013, Alex Gaynor wrote: > Sorry, I misunderstood the original request. Yes, you're right Anssi and > Adrian, finding them on demand is reasonable. > Reasonable, but not entirely necessary for this. I have code that requires something like that; when it is time to "undefer"

Re: Changing deferred model attribute behavior

Hi again, On Friday 26 April 2013, Anssi Kääriäinen wrote: > [...] > In almost every case it is better to try to minimize the amount of > queries than the amount of loaded fields. The cases where you have > deferred multiple fields, need only one of them later on, and there is > a field that you

Re: design decisions for django-mssql: (switching on autocommit and remote proxy) advice wanted.

On Tuesday 30 April 2013, VernonCole wrote: > Dear knowledgeable persons: > > I have completed a beta-test version of a Linux remote access server for > adodbapi, and have started the process if integrating them into > django-mssql. (This is going to be an interesting experience for me -- I >

Re: Django 1.6 release timeline

On Tuesday 30 April 2013, Jacob Kaplan-Moss wrote: > Hi folks - > > Unless there are strong objections, here's what I'm thinking for the > Django 1.6 release timeline: > > Alpha: May 16 > Beta: June 20 > RC: Aug 1 > Final: as early as Aug 8, or later if more RCs are needed. > I see one issue

Re: runserver fails on non-fatal model validation errors

Hi all, I've been going through what I've missed on the list, and found this 2-month- old message that seems to have gone unanswered. I'm sorry for being so late to the party, but... On Saturday 23 March 2013, Brendan Jurd wrote: > > I reported an issue with runserver on the django trac [1],

Triaging: Close as needsinfo

Hi Django devs, I would like to raise a little concern I ran into lately. When going over some Oracle-related tickets, I came across ticket #20201[0] . The ticket description was missing important details, so I commented about them. A few days later, Aymeric came around, and closed the ticket

Re: first() and last(), earliest() and latest()

Hi Selwin, On Saturday 11 May 2013, Selwin Ong wrote: > Hi everyone, > > I submitted a pull request implementing "first()" and "last()" here: > https://github.com/django/django/pull/1054 > > Comments welcome! > You implemented the "order_by" parameter as taking only one field name; this is

Re: reconsider re-opening ticket 901

On Saturday 11 May 2013, Anssi Kääriäinen wrote: > > - While it might seem trivial to implement reload()/refresh() when > needed, Indeed, it might; which is why I would assume many people have already done it. For these people, a new reload()/refresh() in core may go unnoticed or redundantly

Re: reconsider re-opening ticket 901

[resend, reference included; sorrt for the noise] On Saturday 11 May 2013, Anssi Kääriäinen wrote: > > - While it might seem trivial to implement reload()/refresh() when > needed, Indeed, it might; which is why I would assume many people have already done it. For these people, a new

Re: Triaging: Close as needsinfo

On Sunday 12 May 2013, Łukasz Rekucki wrote: > Hi, > > On 11 May 2013 22:58, Shai Berger <s...@platonix.com> wrote: > > In > > other communities, I have usually seen "needsinfo" as a ticket state, > > rather > > than a reason for closing; such

Re: reconsider re-opening ticket 901

Hi, There's one minor issue that I'm not entirely clear of with this proposal: On Sunday 12 May 2013, Anssi Kääriäinen wrote: > > Concrete API proposal: Model.refresh() reloads all non-deferred local > field values (that is, all fields in the current model which have a > database column). In

Re: reconsider re-opening ticket 901

On Sunday 12 May 2013, Aymeric Augustin wrote: > On 12 mai 2013, at 10:24, Shai Berger <s...@platonix.com> wrote: > > Relatedly, we now cache back-references of 1-to-1 relations on the > > instance > > Django has cached them for a long time. It's just a bit more ef

Re: Perception of attitude in tickets

Hi, On Monday 13 May 2013, Tom Evans wrote: > > Perhaps this wasn't clear, that was a member of your community trying > to make it happen. There have been several attempts over the past 5 > years by people trying to make it happen. Each time someone has tried > to make it happen, after the

Re: Perception of attitude in tickets

Hi Tom, On Monday 13 May 2013, Tom Evans wrote: > > You're not the only person who has time constraints, each of has a > choice of what we work on in our spare time. When I read these sorts > of tickets, perfectly valid feature requests knocked down for > precisely no reason, why should I waste

Re: reconsider re-opening ticket 901

On Tuesday 14 May 2013, Alex Ogier wrote: > > It's a totally new behavior that has > plenty of corner cases such as foreign keys, and especially OneToOneFields. > Another one is initializers: get() or any other method of fetching an object from the database will call __init__() with the fields

Re: Perception of attitude in tickets

On Wednesday 15 May 2013, Luke Plant wrote: > > So I've gone ahead and created a wiki page, which can be longer and more > friendly, and require a shorter response on the actual ticket, something > like this: > > Closing as WONTFIX because ... > > If you want to persuade us otherwise,

Remote participation in sprints

Hi all, This saturday and sunday there are supposed to be sprints in DjangoCon EU in Warsaw. To my regret, I could not be present at the conference. However, I may be able to set aside the two days and participate in the sprint remotely. Will there be an effective way to do this while

Re: Reminder: pending Oracle fixes and issues

Hi, Resurrecting a 4-month-old thread: On Sunday 20 January 2013 10:05:16 Anssi Kääriäinen wrote: > On 20 tammi, 02:52, Shai Berger <s...@platonix.com> wrote: > > Which still leaves two issues -- PR #393 (faster processign of numbers; I > > think I forgot to mention earli

Re: first() and last(), earliest() and latest()

Two notes: 1) I think it is better to leave the *args, **kw on the manager methods; since they are just forwarding to the qset anyways, there's no harm in that, and it makes them more "future proof" (i.e. you wouldn't need to change them next time you change the interface of the qset methods).

  1   2   3   4   5   6   7   >