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
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
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,
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
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
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
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.
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
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
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
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
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
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()
>
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
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
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.
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
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.
>
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
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
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
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":
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
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 =
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
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
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
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
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
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?
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
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
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
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'
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
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, )
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
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
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
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,
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
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
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
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
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)
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:
> >>>
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
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
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
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
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
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
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
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
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
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.
--
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"
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
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
> >
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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);
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
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
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
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
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
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
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
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.
>
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"
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
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
>
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
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],
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
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
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
[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
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
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
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
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
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
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
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,
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
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
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 - 100 of 620 matches
Mail list logo