Allow Django to use the INSERT...RETURNING functionality of PG 8.2+
even if autocommit isn't being used.
-- Get rid of the need to repeatedly call SELECT version().
Some other functionality that's not directly relevant to this ticket,
but related and useful:
-- Allow for Serializable transact
was introduced into 8.2, and that syntax is required for correct
operation while autocommit is True. But I'm not sure I understand the
reasoning; does anyone know why INSERT ... RETURNING is required in
that case?
Thanks!
--
-- Christophe Pettus
x...@thebuil
On Nov 8, 2009, at 8:39 AM, Seb Potter wrote:
> transaction pooling
Ah, of course. Thank you!
--
-- Christophe Pettus
x...@thebuild.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django de
o the database, using PostgreSQL
8.4.1, using psycopg2, if that INSERT is the first thing done by a
view on a particular connection to the database, when DATABASE_OPTIONS
autocommit: True is set.
Comments welcome, thanks!
--
-- Christophe Pettus
x...@thebuild.com
--
You received this me
the review process.
Thanks!
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, s
ield. A SlowLoris or similar attack would seem to be far more effective
and less implementation-dependent.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group,
e the decorators call managed(True)), which
means that _leave_transaction_management in the psycopg2 backend will not reset
the transaction isolation level; the code in the psycopg2 backend seems to
assume that it will be run in the new transaction context, not the previous one.
Or am I missing s
xample, on PostgreSQL,
ABORT; DISCARD ALL is the recommended way of resetting a connection, so being
able to implement that would be great.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To u
have this configuration, it's an error. The fact that the error is now
surfacing doesn't make it a correct configuration.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To un
s finished.
If you have more workers than database connections, you have either (a)
over-configured the number of workers, which is generally a bad thing to do, or
(b) you are accepting that you will at high-load points get refused
connections. I don't see either one as being correct.
--
-
On Mar 1, 2013, at 4:48 AM, Aymeric Augustin wrote:
> Yay or nay?
+1.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails fro
ge-case-y. Does it exist
in any case besides model inheritance? If not, could we have the ORM wrap
those operations in a transaction in that particular case?
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Djan
ing
> it from PostgreSQL to BSD.
Absolutely; it would be my honor. Just contact me off-list and we can sort out
the details.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsu
On Mar 4, 2013, at 5:00 AM, Aymeric Augustin wrote:
> PostgreSQL and Oracle use the "repeatable read" isolation level by default.
Without explicitly changing it, PostgreSQL's default is READ COMMITTED. Or are
we setting it explicitly to REPEATABLE READ in the new model?
On Mar 4, 2013, at 7:24 AM, Aymeric Augustin wrote:
> PostgreSQL and Oracle use the "read committed" ...
Sorry, replied too soon!
> The reasoning and the conclusion still stand.
Agreed.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you a
On Mar 17, 2013, at 10:33 AM, Aymeric Augustin wrote:
> Would anyone like to review it?
I only had a chance for a once-over-lightly, but +1 to committing it from my
pass; it looks very valuable.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you
formance issues all by itself:
http://thebuild.com/blog/2014/11/18/when-limit-attacks/
There's no clean fix that wouldn't have significant effects on unsuspecting
applications.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscrib
application is sending a query that
expects to get 100 results back but gets 1,000,000 back, you have a bug that
needs to be tracked down and fixed. Patching it by limiting the results is
kind of a database version of "except: pass" to get rid of an inconvenient but
mysterious except
ch the bad application. To
me, this is about as logical as putting in DIVIDE_BY_ZERO_RETURNS_NONE with a
default of False because someone wrote some legacy code that would work if we
did that.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to
reating the Django and psycopg2 objects
does.
I'll note also that it's not that server that dies in this case; the particular
thread doing the request gets an exception.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Googl
rticular case, where you have the relatively unusual situation that:
1. You have this problem, and,
2. You can't fix the code to solve this problem.
... you probably have the right answer is having a local patch for Django.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this
observation.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to djang
. This
effectively prevents me from logging into the admin. I assume this has
something to do with the redirection change in 1.7 for the admin login.
If I change the name of /login to /customer_login, that confusion goes away.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this
Ignore my silliness... operator error, that the 1.7 change flushed out!
On Apr 6, 2015, at 11:36 PM, Christophe Pettus wrote:
> I have a site with a /login URL. This URL is for customer logins to an
> ecommerce site, and is distinct from the /admin/login to the Django admin.
>
ongly advise *against* *ever* even mentioning fsync =
off anywhere in the Django documentation; that is such a horribly bad idea in
99.95% of real-life situations that steering people towards it as a "go faster"
button is very unwise.
--
-- Christophe Pettus
x...@thebuild.com
--
aluable, and advising them to do a setting that runs the risk
of them losing that data seems like a bad idea.
The Django documentation is not the place to go into the ramifications of fsync
(or even synchronous_commit, although that's significantly less risky).
--
-- Christophe Pettus
.
>
> Having a fast test suite is such an important part of development that it
> shouldn't be held back by attempting to protect the world from people who
> cannot be helped.
>
> Luke
>
> On 16/07/15 16:49, Christophe Pettus wrote:
>> On Jul 16, 2015, at 1
#x27;s point at the people whose
>>> responsibility it really is :)
>>>
>>> --
>>> Curtis
>>>
>>> On 20 July 2015 at 06:44, Aymeric Augustin
>>> wrote:
>>>> I agree with pointing to the relevant section of the PostgreSQL
>
egroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1FQAJqrXu3HcSpP3xDF%2BA
nceptually they're different things.
I don't think the relatively modest benefit of having no default justifies the
problems that result on other platforms.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"
obvious gain. What's the benefit there?
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emai
that something bad doesn't get into the database.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiv
st for because it is required
> for the database backend.
Well, that's not a practice I think we need to go to great lengths to support.
If you *really* *must* have a VARCHAR field without a length, you can always
use a migration to strip it off.
--
-- Christophe Pettus
x...@thebui
ng less depending on
Oracle's encoding?
Requiring a max_length is enforcing a good practice.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsub
, you just use TextField, and if you are either targeting
a different database, or writing one that runs on multiple ones, you probably
want CharField with a specific length.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
&qu
't think of it.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an emai
t correct? My understanding was that the passwords were only modified
when changed. Given that it is a unidirectional hash, I'm not sure how they
*would* be rehashed.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google G
roblem, since it's no worse than a user resetting their password.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group an
ould be near-free on
any back-end, since there are no changes, and it eliminates the IIT issue on
PostgreSQL (and perhaps other problems on MySQL that I'm not as familiar with).
What am I missing?
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscr
On Oct 22, 2010, at 4:01 PM, Jacob Kaplan-Moss wrote:
> It's a bug: http://code.djangoproject.com/ticket/9964.
>
> Looks like the patch there is OK, but still needs some work (there's a
> couple of TODOs still).
On it! :)
--
-- Christophe Pettus
x...@thebuild.com
t is closed... somehow, by some means
(probably a rollback when the connection closes). Is this really
explicit-enough behavior that maintaining it is important? Are applications
really relying on it?
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are sub
behavior. In the proposed fix, such transactions will
commit instead. This is, however, pretty much the same as relying on
uninitialized values in memory to be consistent, and I don't see any reason not
to declare such code buggy.
I've gotten around this by having my own version of commit_o
it does not.
(Optional: Adding the algorithm as a default parameter to User.set_password().)
Comments?
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
ite the passwords to disk, and having an architecture to handle this
seems like a good idea.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop..
f passwords and
their hashes, (pwd, hash(pwd)). The attacker then runs down the dictionary,
comparing hashes; if they get a hit, they know the password. The salt defeats
this by making the pwd -> hash(pwd) mapping incorrect.
--
-- Christophe Pettus
x...@thebuild.com
--
You received
for a plain dictionary attack, either, for the same reason
as a brute force attack.
Anyway, back to the discussion of the actual proposal. :)
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" gro
lication can brute force 700 million MD5s per second, doubling the length is
not really going to make it any more secure.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this g
e entropy in the password
selection. If everyone has a unique password, it doesn't help at all
(admittedly unlikely). Again, it's a linear benefit, but not an exponential
one.
Right. So, about that proposal... :)
--
-- Christophe Pettus
x...@thebuild.com
--
You received
AUTOCOMMIT: True in the database
options). Is there some quick guidance from those more experienced than me?
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send ema
te).order_by('entry_date').limit(limit=1,
offset=0)
Then, in the template, {{ previous_entry.get }} could be used to fetch the
result.
Thoughts?
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django deve
mind, and
thanks. :)
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
On Dec 8, 2010, at 12:08 PM, Jonas H. wrote:
> Can the time spent in *one single string comparison* really make such a huge
> difference?
Yes.
http://codahale.com/a-lesson-in-timing-attacks/
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because y
ts of
GET_ITERATOR_CHUNK_SIZE (which is hard coded right now to be 100). So, in the
case of using .iterator() (no caching of results), it shouldn't have more than
100 result objects in memory at once, unless the client of the query set is
saving them. Am I reading it correctly?
--
-- Christophe P
is done.
If I'm understanding your point, this isn't true; NULL does not match NULL on a
join.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to thi
it should never return related
objects; ditto for the reverse situation.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@g
On Dec 21, 2010, at 11:39 AM, Jacob Kaplan-Moss wrote:
> Unless there are objections, I'm going to accept this approach and
> check in a change based on Shai's latest -bugfix patch.
FWIW, +1.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because yo
27;s stored in pg_depend.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send em
rror
exception thrown instead.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, s
You must know what you are doing" feature in
the first place, I don't see the need to be strict about the input, at the cost
of some very useful functionality.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
are doing, so let's just get out of
their way and let them get on with it.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developer
On Mar 12, 2011, at 12:56 PM, Jacob Kaplan-Moss wrote:
> Christophe, can you write a patch including a new warning to put in the docs?
All set: http://code.djangoproject.com/ticket/14733
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed
dering of the fields in the
class declaration becomes important. That could, potentially, be surprising.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, s
osite field. In all of these cases, what we're really
creating is a composite index on a set of standard fields. Introducing a more
powerful index-creation syntax into Django isn't a bad idea, but we shouldn't
call it a "field" if it is not.
--
-- Christophe Pettus
ble, and have db_index=True be a shortcut to creating one. That
might be more machinery than we want just for composite primary keys though.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers&qu
I'd like to make one more pitch for a slightly different implementation here.
My concern with CompositeField isn't based on the fact that it doesn't map
one-to-one with a field in the table; it's that it doesn't have any of the
semantics that are associated with a field. In particular, it can'
Django core, especially given the varying
implementations for specific environments.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegr
indexes = ['some_field', 'some_other_field', ('field1',
'-field2', ), ]
raw_indexes = [ 'some_invariant_function(some_field)' ]
(This was proposed by someone else, and isn't original to me; apologies that I
can't find the
at an inner
template is used in multiple wrapper contexts. Is this something that might be
worth investigating in Django? Looking at the Django source, the
implementation seems quite straight-forward.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because yo
st the DB to see if the problem is in MySQL, or in the Django backend.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@goog
On Oct 6, 2011, at 9:29 PM, Tai Lee wrote:
> Why is ROUND_HALF_EVEN superior?
ROUND_HALF_EVEN is the standard when doing financial calculations, an extremely
common use of DecimalField.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed
work for existing applications.
I also think we *really* need to push execution of this functionality into the
database rather than having the Django core do it, if we're going to be making
more use of on_delete.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message be
us, error-prone South
migration to install the appropriate foreign key constraints, something that
Django could very easily do.
Perhaps a CASCADE_DB and SET_NULL_DB options on on_delete?
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the G
On Sep 26, 2013, at 3:28 PM, Christophe Pettus wrote:
> Perhaps a CASCADE_DB and SET_NULL_DB options on on_delete?
And, to be clear, I *am* volunteering to take a go at this code, not just
whine. :)
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you
disallow that.
(b) You allow it, but warn that if you delete the child, the parent is not
cleaned up.
I lean towards (a).
--
The _DB variations should be considered something like .update and .raw;
they're for performance benefits where you know you are doing. They don't need
to solve eve
> --
> 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,
uot; where I assume "clean" means "with reasonable behavior
in the presence of concurrent activity" and MERGE means "the MERGE statement
defined in the standard" is a contradiction in terms, and expecting PostgreSQL
to square that circle isn't a reasonable re
have saved a major foot-gun of either integer exhaustion or
a very expensive data migration problem.
--
Comments?
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)&quo
is to make the public default for new projects 64
bit keys; we're doing developers a disservice by making the default path 32 bit
keys.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contrib
te must be marked IMMUTABLE
xof=# create index on i(p) where p > '2011-01-01'::timestamp;
CREATE INDEX
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself
> On Jul 23, 2018, at 13:05, Christophe Pettus wrote:
>
>
>> On Jul 23, 2018, at 12:20, Mads Jensen wrote:
>>
>> Q(published__gt=datetime.date(2017, 10, 1))
>> =>
>> "table"."published" > '2017-10-01'::timestamp;
>
80 matches
Mail list logo
