There was a recent query about prepared statements on the db-sig mailing
list, too. Apparently thought is being given to adding such functionality
to Psycopg. If such functionality is added, it could be useful to support,
I suppose. Some SQL engines apparently benefit from the techinque. MS SQL
There has been quite a discussion on the ticket regarding this
Refs. : https://code.djangoproject.com/ticket/22268
I think we must discuss and decide what should be the solution we should be
working towards.
Until now there have been two strategies:
1.) The query generated is correct therefore,
W
>
> 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 even bigger - if you "syncdb" an app with migrations to a main
I read on google melange:
"mentoring organizations may request further proposal detail from the
student applicant."
My tests are about to start so I want to know if and when should I be
expecting this.
Regards,
Anubhav
--
You received this message because you are subscribed to the Google Grou
On 27 March 2014 19:11, VernonCole wrote:
> There was a recent query about prepared statements on the db-sig mailing
> list, too. Apparently thought is being given to adding such functionality
> to Psycopg. If such functionality is added, it could be useful to support,
> I suppose. Some SQL engin
As far as I know, we have no plans to request further details from any of
our applications.
On Thursday, March 27, 2014 5:46:55 AM UTC-4, anubhav joshi wrote:
>
> I read on google melange:
> "mentoring organizations may request further proposal detail from the
> student applicant."
>
> My tests
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,
Ok. Thanks
Anubhav
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to dja
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
On 27 mars 2014, at 15:20, Shai Berger wrote:
> However, with any backend, select-for-update in autocommit mode makes very
> little sense. Even if it doesn't break (as it does on Oracle), it doesn't
> really lock anything. So, IMO, executing a query that is a select-for-update
> in autocommit
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
On Thu, Mar 27, 2014 at 1:10 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
> On Wed, Mar 26, 2014 at 8:19 PM, Cal Leeming [Simplicity Media Ltd] <
> cal.leem...@simplicitymedialtd.co.uk> wrote:
>
>>
>>
>>
>> On Tue, Mar 25, 2014 at 11:40 PM, Russell Keith-Magee <
>> russ...@keith-mag
You're missing an important third option here: do nothing, and document the
fact that "values" over an m2m is an inherently nonsense operation in an
ORM context.
values() and values_list() are both intended as optimisations for a
specific use case - retrieval of subsets of data without the overhea
If I need to take either of these options I'd tend towards Shai's one - we
don't want to allow people to just disable migrations on a per-database
basis, that's bound to get someone into trouble. That said, the flag is
going to be weird to explain to people.
Just to establish a baseline, would you
> values() and values_list() are both intended as optimisations for a
> specific use case - retrieval of subsets of data without the overhead of
> creating a model instance. This metaphor completely falls apart when
> dealing with m2m relations, because the the "one row, one object" metaphor
On Fri, Mar 28, 2014 at 2:29 PM, anubhav joshi wrote:
>
> values() and values_list() are both intended as optimisations for a
>> specific use case - retrieval of subsets of data without the overhead of
>> creating a model instance. This metaphor completely falls apart when
>> dealing with m2m rela
16 matches
Mail list logo
