Re: Should DecimalField have special rounding to make float assignments match string assignments?

On 5 April 2016 at 14:49, Tim Graham wrote: > The default behavior of decimal rounding is ROUND_HALF_EVEN (to nearest with > ties going to nearest even integer). There's a proposal to change this to > cast floats to string and then use ROUND_HALF_UP to match the value of >

Re: MOSS Award to Django

On Wed, Dec 16, 2015 at 6:22 AM, Andrew Godwin wrote: > > > On Wed, Dec 16, 2015 at 9:52 AM, Markus Holtermann > wrote: >> >> >> >If I get it right -- Curtis' description is spot-on; some tasks will >> >still >> >need Celery, Channels will take care

Re: Speedy Mail 2.0 - a new webmail platform in Python and Django

On Tue, Jul 21, 2015 at 1:05 PM, Uri Even-Chen wrote: > > By the way, is there a simple way to convert PHP software to Python, or do we > have to rewrite in again line by line? if you do, you wouldn't gain anything. the advantage isn't in the language, it's in the

Re: Feature: Support a javascript template language on the server

On Sun, May 31, 2015 at 5:21 PM, Emil Stenström wrote: > Are you saying you prefer implementing all templates in two languages, since > implementing views twice is too much work? The time you save being able to > reuse the same templates in the client side is huge, and avoids the >

Re: Feature: Support Server-Sent Events

On Sun, May 31, 2015 at 3:52 AM, Emil Stenström wrote: > Could you help me understand why this have to be done inside a web server > container? AFAICT, it doesn't have to be done in the container, but currently it must be 'outside' of Django. But having help from the container

Re: Feature: Support Server-Sent Events

On Sun, May 31, 2015 at 1:23 AM, Roberto De Ioris wrote: > I obviously agree, but take in account that this uWSGI plugin simplified > the steps a lot: > > https://github.com/unbit/uwsgi-sse-offload nice. it certainly looks cleaner than having an external gevent process. does

Re: Feature: Support Server-Sent Events

On Sat, May 30, 2015 at 4:19 PM, Florian Apolloner wrote: > ie how would it use Django's current featureset which is basically blocking > everywhere… On Sat, May 30, 2015 at 4:40 PM, Emil Stenström wrote: > The separate process would have none of Django's

Re: Remove autogenerated 'id' when using existing database

On Tue, Apr 28, 2015 at 1:59 AM, Ben in campus wrote: > That table does NOT have column 'id', so the generated models.py doesn't > have 'id' either. The model is unmanaged (managed = False). if your table has a primary key, add the primary_key=True flag to that field and

Re: #23646 Enhancement: Updating multiple values in a single sql update using Django ORM

On Mon, Oct 20, 2014 at 1:03 AM, Anshuman Aggarwal wrote: > The idea of having a .update() ORM construct is to be able to do this > without having to fall down to a manual transaction every time, otherwise > why have a DB level .update()...I am sure the performance of

Re: Querying across FK produces too many OUTER JOINs (1.6) or FieldError (1.7)

On Fri, Jul 4, 2014 at 5:23 PM, Stephen J. Butler wrote: > * Build a list of relevant containers first: > Container.objects.filter(item__previous__isnull=True, > item__flag=True).values_list('pk', flat=True). Then > Items.objects.filter(current=True,

Re: Querying across FK produces too many OUTER JOINs (1.6) or FieldError (1.7)

On Fri, Jul 4, 2014 at 4:42 PM, Jon Dufresne wrote: > Item.objects.filter(current=True, > container__item__previous__isnull=True, container__item__flag=True) > --- > > That is, I'm looking for all current items such that the first item in > the chain has flag = true.

Re: Django ORM support for NoSql databases

On Wed, Dec 18, 2013 at 12:18 PM, wrote: > > Wouldn't an easy (i.e. straightforward) solution be to add an Django "ODM" > that mirrors the ORM wherever it makes sense? This sounds pretty close to > your second solution, except choosing SQL vs NoSQL means

Re: Django ORM support for NoSql databases

ussel: On Tue, Mar 26, 2013 at 6:49 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > > On Wed, Mar 27, 2013 at 12:46 AM, Javier Guerra Giraldez <jav...@guerrag.com> > wrote: >> >> On Tue, Mar 26, 2013 at 11:10 AM, Donnie Darko <gittest...@gmail.com>

Re: BCrypt and PBKDF2 Password Hash Caching

On Tue, Nov 19, 2013 at 8:48 PM, Erik van Zijst wrote: > You make a good point. > > An obvious fix would seem to be to add the username to the cache key. This > way users cannot "use" another user's cache entry. right, that would fix it. (i guess, i'm no security

Re: BCrypt and PBKDF2 Password Hash Caching

On Fri, Nov 15, 2013 at 2:27 PM, Marc Tamlyn wrote: > That said, sounds an interesting solution and would make a good library. > However I'm not knowledgeable enough to say if it is a good idea from a > security perspective. imagine this scenario: an attacker gets the

Re: #18659 -- Deprecating request.REQUEST

of functionality. On Wed, Oct 16, 2013 at 11:29 AM, Tim Chase <django.us...@tim.thechases.com> wrote: > On 2013-10-16 11:10, Javier Guerra Giraldez wrote: >> On Wed, Oct 16, 2013 at 10:14 AM, Shai Berger <s...@platonix.com> >> wrote: >> > However, it does so by

Re: #18659 -- Deprecating request.REQUEST

On Wed, Oct 16, 2013 at 10:14 AM, Shai Berger wrote: > However, it does so by blurring the distinction between GET and POST > parameters, which like other people here, I find disturbing. care to elaborate about that distinction? both are user-provided parameters included in

Re: Thinking about NoSQL support

On Thu, Sep 5, 2013 at 7:44 PM, Curtis Maloney wrote: > But trying to shoe-horn a single API onto all models won't work. +1 to this. there are lots of kinds of databases, relational, hierarchical, object based, key-value, document-based, column-oriented, graphs,

Re: Deprecate FCGI support in Django 1.7

On Tue, Aug 6, 2013 at 9:40 AM, Andre Terra wrote: > Assuming a UNIX environment. In Windowsland, nginx is still one of the best > alternatives. I meant use those _behind_ NginX. neither is really good as an external-facing HTTP process. -- Javier -- You received this

Re: Deprecate FCGI support in Django 1.7

On Tue, Aug 6, 2013 at 6:28 AM, VernonCole wrote: > I had come the the conclusion that FastCGI was the only way behind NginX, the best two options seem to be uWSGI and gunicorn. personally, I like uWSGI, but both are quite performant and low-resource. -- Javier -- You

Re: Deprecate FCGI support in Django 1.7

On Sun, Jul 21, 2013 at 11:39 AM, Juan Luis Boya wrote: > * An asynchronous server may be attending many client connections at a time > for each worker thread. Concurrency is achieved within the thread using an > application specific dispatcher. In an asynchronous server, there

Re: Deprecate FCGI support in Django 1.7

On Thu, Jul 18, 2013 at 5:30 PM, Juan Luis Boya wrote: > uWSGI + FastCGI: We should have nice docs about this. as others have previously said, uWSGI isn't viable for everybody. is there any other pure-python fcgi-wsgi server with reasonable performance? i think several

Re: Meta-Proposal: Write *above* quotations in mailing list replies

On Tue, Jun 4, 2013 at 5:14 PM, Yo-Yo Ma wrote: > Thoughts? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- Javier -- You received this

Re: Ability to save 4xx messages to database

On Thu, Apr 11, 2013 at 2:09 PM, Babatunde Akinyanmi wrote: > Hi Javier, why no for small deployments, with a single django app server, just logging to a file and analyzing with grep works really really well. for larger deployments, where you have more than one django

Re: Ability to save 4xx messages to database

On Thu, Apr 11, 2013 at 10:21 AM, Val Neekman wrote: > Now, the $64 K question: is Django a good place for this? I'd say no. the best place would be a monitoring system. a surprisingly good approach is to use rsyslog protocol, and add a good event storage backend to the

Re: Enhance class Storage with additional methods

On Wed, Apr 10, 2013 at 3:39 AM, Ioan Alexandru Cucu wrote: > I feel like this kind of functionality should be handled by the storage > object itself. check django-storages http://django-storages.readthedocs.org/en/latest/ it includes several storage backends, S3

Re: Implementing Full Text Search in Django --Ticket #3254

On Thu, Mar 21, 2013 at 8:51 PM, Luke Sneeringer wrote: > InnoDB supports foreign key constraints but not full-text indexing, while > MyISAM supports full-text indexing but not foreign-key constraints. InnoDB does support full-text search since MySQL 5.6

Re: Moving database backends out of the core

On Sat, Mar 9, 2013 at 4:58 AM, VernonCole wrote: > But will this situation ever exist in real life? I don't think so. I > suspect that any heavy-use shops will also be using Windows to run their > django servers. to me, that reads "heavy clients of MSSQL have to run

Re: Moving database backends out of the core

On Fri, Mar 8, 2013 at 4:25 AM, VernonCole wrote: > People tend to think of ADO as only talking to Microsoft databases. Nothing > could be farther from the truth. When maintaining adodbapi, I normally test > against MS-SQL Server, Microsoft "Jet" (a.k.a. ACCESS), MySQL,

Re: Proposal: deprecate and remove django.contrib.comments

On Thu, Mar 7, 2013 at 12:41 PM, Luke Granger-Brown wrote: > I've only tried using django.contrib.comments once, and it ended up not > being what I needed anyway, so I had to write my own comments module (Disqus > was out of the question) i had exactly the same experience.

Re: Switch to database-level autocommit

On Wed, Mar 6, 2013 at 4:15 AM, Jeremy Dunck wrote: > I, for one, would prefer that we not recommend TransactionMiddleware > so highly. then what would be the recommended option to have transactions tied to the request/response cycle? probably @commit_on_success for every view

Re: Switch to database-level autocommit

On Fri, Mar 1, 2013 at 7:48 AM, Aymeric Augustin wrote: > To alleviate the pain, Django commits after each ORM write. just curious: why is it so? i can't think of any reason not to tie transaction to the request/response cycle by default. (ie what

Re: Can you confirm Stack Overflow answer about `.exists()`?

On Fri, Jan 18, 2013 at 10:58 AM, Ram Rachum wrote: > I suggest copying your explanation into the documentation. it's already there: " This means that calling QuerySet.exists() is faster than bool(some_query_set), but not by a large degree. If some_query_set has not yet been

Re: Improved ajax support idea

On Sun, Nov 25, 2012 at 12:04 PM, James Pic wrote: > it would be great if we could make urls easier to reverse in Javascript. you shouldn't have to. good REST design means not using database IDs. any response that references server resources should send a whole URL. no need

Re: Custom ForeignKey which does not require referential integrity?

On Tue, May 29, 2012 at 8:21 AM, diabeteman wrote: > I posted first on django-users and then I thought that it was a bit too low > level for such a question. Django-devs is _not_ a "Django support, level 2" list. :-) -- Javier -- You received this message because you

Re: #18094: signals, model inheritance, and proxy models

On Thu, Apr 12, 2012 at 12:19 PM, Carl Meyer wrote: > Also, it isn't really true that the model signals are strictly tied to > database activity; they are tied to events on Python model objects. One > of the three signals under discussion is the pre/post_init signal, which >

Re: #18094: signals, model inheritance, and proxy models

On Thu, Apr 12, 2012 at 11:31 AM, Carl Meyer wrote: > Thoughts? in my mental model, there are three types of inheritance: concrete: two tables, deletion should fire two signals, one for the child record and one for the parent record. abstract: there's no parent table,

Re: MySQL connection pooling - preferred method??

On Fri, Feb 17, 2012 at 4:58 PM, Florian Apolloner wrote: > This approach has quite a few issues on it's own, eg for postgres if the > transaction is broken all following requests will raise a 500. You have to > at least reset the connection state to something useable

Re: GSoC 2012 Proposal

On Tue, Feb 7, 2012 at 2:26 PM, Victor Buldakov wrote: >  In my project I would like to develop the support of block with use > of the python code. >  In my opinion, it would make Django templates more flexible and > power. from the "Philosophy" section of the template

Re: Speeding up tests

On Mon, Jan 16, 2012 at 11:46 AM, Anssi Kääriäinen wrote: > I have been investigating what takes time in Django's test runner and > if there is anything to do about it. The short answer is: yes, there > is a lot of room for improvement. I managed to reduce the running >

Re: queryset caching note in docs

On Wed, Nov 2, 2011 at 11:33 AM, Tom Evans wrote: >> other connections in other transactions are locked too? > > Yes. The exact wording from the C API: > > """ > On the other hand, you shouldn't use mysql_use_result() if you are > doing a lot of processing for each row

Re: common variable (Deploying Feature in manage.py)

On Tue, Oct 25, 2011 at 9:29 AM, Tom Evans wrote: > I honestly think that trying to integrate any sort of deployment > features in django will only please the few people who use that > particular method of deploying code, and irritate the majority who do > it in a

Re: Sane defaults for Startapp and Startproject

hi, here are my personal thoughts on the proposals: On Tue, Oct 18, 2011 at 5:21 PM, Rich Jones wrote: > django-admin.py startproject newproj > > should create ./static, ./uploads and ./newproj and ./newproj/ > templates -0 ./static might be common, the others are way too

Re: Feature request prop for django db cache extention

On Fri, Oct 14, 2011 at 9:13 PM, Cal Leeming [Simplicity Media Ltd] wrote: > In the end, we monkey-patched the code so raw SQL statement was used to > generate a cache key, and we performed a lookup on that. why SQL? it seems a memcached INCR would be faster

Re: Feature proposal: Q.push(...) and QuerySet.filter(relfield=Q(...))

On Tue, Oct 4, 2011 at 4:35 AM, Johannes Dollinger wrote: > as you could write Q(foo=Q(...)) instead of Q(..).push('foo') I thought that would work magically, since the Q object would just pass that to the filter(); but a quick test proved me wrong. I've just refactored

Re: Feature proposal: Q.push(...) and QuerySet.filter(relfield=Q(...))

On Tue, Oct 4, 2011 at 4:35 AM, Johannes Dollinger wrote: > Thanks for starting this! > Why did you chose a staticmethod instead of an instancemethod? because it's applied recursively not just to tree.Node, but to the children and all members. it would be cleaner as a

Re: Feature proposal: Q.push(...) and QuerySet.filter(relfield=Q(...))

On Fri, Sep 30, 2011 at 4:37 PM, Johannes Dollinger wrote: > The aim of this proposal is to reuse Q objects for models that are related > through FK or M2M fields. i really want to have this feature! so i went and did a quick implementation and created ticket #16979[1]

Re: Semantics when calling select_related repeatedly

On Tue, Sep 20, 2011 at 11:29 AM, Jeremy Dunck wrote: > It seems to me that calling .select_related should be additive +1 -- Javier -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: RFC: "universal" view decorators

On Fri, Sep 16, 2011 at 8:34 AM, Reinout van Rees wrote: > Watch out, in general, with adding more and more mixins. > > I explained just the most basic template CBV to a colleague: there are just > two mixins and a base class there, but his eyes already started to glaze >

Re: Logging all/slow queries

On Tue, Jul 19, 2011 at 12:16 PM, David wrote: > This does duplicate > some functionality of RDBMSs but aggregating queries across multiple > databases is really convenient rather than having to go to each > database's logs. i'd also like something like that to have better

Re: Storing IP address as integer within database to remove need for full text search

On Mon, Jul 18, 2011 at 10:13 AM, Javier Guerra Giraldez <jav...@guerrag.com> wrote: > On Mon, Jul 18, 2011 at 9:56 AM, Cal Leeming [Simplicity Media Ltd] > <cal.leem...@simplicitymedialtd.co.uk> wrote: >> It stores the IP address in integer form, meaning the lookups on

Re: Storing IP address as integer within database to remove need for full text search

On Mon, Jul 18, 2011 at 9:56 AM, Cal Leeming [Simplicity Media Ltd] wrote: > It stores the IP address in integer form, meaning the lookups on large > tables are much faster: are they?hashtables shouldn't be too sensitive to key size, as long as the

Re: Conditional aggregations.

On Tue, Jun 28, 2011 at 9:26 AM, akaariai wrote: >> this looks quite non-portable > > How? The CASE statement is specified in SQL standard, and it is > implemented in all database I have used. i might be totally wrong (wouldn't be first time..) but i've found myself having to

Re: Conditional aggregations.

On Tue, Jun 28, 2011 at 8:41 AM, akaariai wrote: > This should translate to the following SQL: > SELECT sum(case when house.price > 41000 and house.price < 43000 then > 1 else 0 end) as expensive_house, >       sum(case when house.price > 43000 then 1 else 0 end) as >

Re: Deprecation policy for IE6

On Sat, Jun 11, 2011 at 1:14 AM, Mateusz Harasymczuk wrote: > If someone moved out of the IE 6, then he/she move out of the IE 7, too. while i agree, i found microsoft's tortuous path to standards full of dark corners. case in point: some time ago, i was using some simple

Re: Deprecation policy for IE6

On Thu, Jun 9, 2011 at 9:44 AM, Aymeric Augustin wrote: > c) need to access a Django application — let alone a Django >= 1.4 app. even less likely: a Django application's admin page -- Javier -- You received this message because you are subscribed to the

Re: RFC: Composite fields API

On Thu, May 12, 2011 at 8:49 AM, Tom Evans wrote: > unique/unique_together: They should both be supported. unique_together > should raise a PendingDeprecationWarning, and it should disappear > according to the deprecation timeline. unique_together only exists as > a Meta

Re: model fields options

On Fri, May 6, 2011 at 12:22 PM, legutierr wrote: > Why is help_text part of the field > definition?  This is a ui-specific thing--what does it have to do with > the database?  All abstractions are leaky, sure, but this seems > inappropriate.  The same thing goes for

Re: Use cases for a OneToMany field

On Wed, Apr 27, 2011 at 2:35 PM, Charlie DeTar wrote: > Is this something that others see value in?  Cause I sure think it > would be awesome. a COMEFROM instruction in Python would be awesome too -- Javier -- You received this message because you are subscribed to the

Re: Composite primary keys

On Tue, Mar 15, 2011 at 7:14 PM, Christophe Pettus wrote: > A concern here is that composite indexes, like unique, are sensitive to the > ordering of the fields, which means that the ordering of the fields in the > class declaration becomes important. a simplistic proposal:

Re: How to concatenate strings in django templates?

On Wed, Dec 8, 2010 at 5:39 AM, Muhammad Ahsan wrote: > {% extend shop/shop_name/base.html %} shop/{{shop_name}}/base.html ... and this is the wrong list -- Javier -- You received this message because you are subscribed to the Google Groups "Django developers"

Re: Feature request: ForeignKey through parameter

On Thu, Oct 28, 2010 at 9:15 AM, Roald de Vries wrote: > On first sight, I think I agree with you that the syntax is cleaner like > this, but I would choose for the through-parameter because it's more > consistent with the use of the through-parameter for ManyToManyField. but

Re: Feature request: ForeignKey through parameter

On Thu, Oct 28, 2010 at 2:54 AM, Roald de Vries wrote: > I quite often reference foreign keys of foreign keys of foreign keys... > Wouldn't it be nice to have a 'through'-parameter for ForeignKey's? > > >    class A(Model): >        b = ForeignKey('B') >        c =

Re: parameterized apps (was: Re: Eric Florenzano's presentation slides)

On Thu, Sep 9, 2010 at 4:02 PM, Alex Gaynor wrote: >>> INSTALLED_APPS = ( >>>        'django.contrib.auth', >>>        'django.contrib.contenttypes', >>>        'django.contrib.sessions', >>>        'django.contrib.sites', >>>        'django.contrib.admin', >>>        

Re: parameterized apps (was: Re: Eric Florenzano's presentation slides)

On Thu, Sep 9, 2010 at 3:59 PM, Russell Keith-Magee wrote: > What you're proposing here is two things: a LazyForeignKey, and > configurable applications. not really, it's only configurable applications. once you have that, it's easy to make the ForeignKey depend on a

parameterized apps (was: Re: Eric Florenzano's presentation slides)

from Eric Florenzano's slide 41: In models.py: class Favorite(models.Model): item = LazyForeignKey(‘fave’) user = ForeignKey(User) date = DateTimeField(default=utcnow) In settings.py: LAZY_FKS = {‘fave’: ‘pages.models.Page’} I share the dislike for generic

Re: Proposal: Revised form rendering

On Mon, Jul 12, 2010 at 8:16 AM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Mon, Jul 12, 2010 at 11:27 AM, Javier Guerra Giraldez > <jav...@guerrag.com> wrote: >> no, the P, UL (and my hypothetical left_table) would each one be a >> class; you co

Re: Proposal: Revised form rendering

On Sun, Jul 11, 2010 at 9:23 PM, Russell Keith-Magee wrote: >  * Duplication. The 'left_table' flag needs to be applied to every use > of the {% form %} tag on a page. If you're > manually rolling out every field on a form, this is a lot of code duplication. absolutely.

Re: Proposal: Revised form rendering

On Sun, Jul 11, 2010 at 9:31 PM, André Eriksson wrote: > {% form myform %} >    {% using birthday=calendar %} >    {% renderer "as_ul" %} >    {% autocomplete "name_autocomplete" %} >    {% doctype xhtml1 %} > {% endform %} i like this syntax; it's a lot more readable than a

Re: Proposal: Revised form rendering

On Sun, Jul 11, 2010 at 12:16 PM, David Larlet wrote: > Le 11 juil. 2010 à 17:36, Russell Keith-Magee a écrit : >> {% load custom_renderer %} >> {% form myform %} >> >> Django would ship with {% form %} implementations of the 'as_p' and >> 'as_ul' strategies, so getting 'as_p'

Re: natural keys and dumpdata

On Fri, Jul 9, 2010 at 8:47 AM, Stijn Hoop wrote: > This is rather impossible without natural keys, for I cannot know the > maximum ID of any primary key of tables that they have added data to. > However with natural keys I can do away with recording the numerical > ID of an

Re: Imports in the tutorial

On Fri, Jun 11, 2010 at 10:16 AM, Andrew Godwin wrote: >> I agree that it is confusing that it will work either way, but I'd >> argue in favor of using the project name everywhere. It is explicit >> instead of mucking around with the Python path behind the scenes. >> > >

Re: Proposal: {% include_partial %} template tag

2010/6/7 Łukasz Rekucki : >>    {% include "some/template.html" with foo=bar baz=spam %} > Personally, I would expect this to extend the current context with > "foo" and "bar", render the include and restore foo, bar to old values > (if any). Using a clean context instead is a

Re: NoSQL Support for the ORM

On Thu, Apr 8, 2010 at 12:08 PM, Waldemar Kornewald wrote: >> No, we don't.  People are desiging there data in ways that fit their >> datastore. If all people did was implement a relational model in >> userland code on top of non-relational databases then they'd really be >>

Re: admin javacripts

On Fri, Feb 19, 2010 at 6:32 AM, Rajeev J Sebastian wrote: > On Thu, Feb 18, 2010 at 8:09 PM, Rob Hudson wrote: >> While certain parts of the admin are (or will be) using jQuery >> (widgets, etc.) > > This really sucks. Kindly don't do this. It

Re: Adding an option to re-test only failed tests

On Fri, Oct 2, 2009 at 5:10 AM, Harro wrote: > > Sounds like a bad plan, what if by fixing the failed test you break > another one? while testing, when i found some not-obvious test failure and i have to run the test repeatedly, i try to run just this one until it passes.

Re: Proposal for contrib feature (DictionaryField in models)

On Tue, Aug 11, 2009 at 2:11 PM, Mark Ferrer wrote: > I call it a DictionaryField and it takes a Python dictionary object and > stores it in a database as a text field i usually just encode it as JSON. not as dense; but more universal syntax, so you get faster decoders in

Re: Offering sponsorship to work on improving Django

On Mon, Jul 20, 2009 at 9:38 PM, Alex Dedul wrote: > Sure, i already wrote about this here with some discussion about > Edubuntu > http://www.reddit.com/r/linux/comments/90brb/creating_a_company_to_develop_maintain_and/ > i applaud your initiative and would really love to

Re: ImageField performance

On Fri, Jul 17, 2009 at 8:10 PM, Fredz./ wrote: > I might be loading the image in memory, but it sure seems 1000x faster > when you reach images the size of 10 megs and more. this assumes that it would have to read the whole file anyway. some formats have the size