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

[Javier Guerra Giraldez]

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
> strings [0][1]. Do you have any concerns about this? Is it something we
> should even care about?


Am I reading it wrong, or the ticket/patch assume that the "correct"
rounding is ROUND_HALF_UP?  In my experience, ROUND_HALF_EVEN produces
less accumulated error after a string of operations.


-- 
Javier

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFkDaoTv3T5PikjLvddX6W3dmyY48qo7tqEwpzYQCpjRv_R2Hg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: MOSS Award to Django

[Javier Guerra Giraldez]

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 of many others.
>>
>> For me it's more a question of "is a client directly involved".

as i read it:

celery has an specific use pattern:  the Django process emits a
message to some other process.  It doesn't alter the request/response
cycle in any way.  the most common use is to initiate a 'background
process' from the request-bound Django process to another, non-Django
process.


The "channels" design makes Django a processor of messages, the first
example is a 'normal' http request, which would be just a message from
the user.  another example is asynchronous request/responses,
typically WebSockets, SSE, etc.   finally, it could also allow a
Django process on the receiving end of an intra-server message.  A
future version of Celery could use that as a new infrastructure
option.


-- 
Javier

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFkDaoRiRJiOUQK-xCi8kwkrR%3DV9K6rMw%2BstZ16ZOrNn7%3D_0Mg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Javier Guerra Giraldez]

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 architecture.


-- 
Javier

-- 
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 django-developers+unsubscr...@googlegroups.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/CAFkDaoS2q7eGV%3DVY1X1L%3DAQ2Ovx0%2BjW2jPrVr0fw8XpzBa%3D4Hg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Javier Guerra Giraldez]

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
> maintenance burden of keeping two identical things in sync.
>
> I'm also not saying you should implement views twice. Each time you click a
> link that request can go to the exact same server side view, get the correct
> data back (only the data), and re-render only the parts that changed.
>
>>
>> Also the need to reimplement django.shortcuts.render is unneded. Add in
>> the base tpl a {% if request.is_ajax %} then wrap the result in a entire
>> html tpl for regular http calls and the new content only in the other case.
>
>
> I'm not sure I follow here. Are you saying I should just go through all my
> templates and split them in two? What do you mean by "new content" here? My
> suggestion is that you would send only the new DATA, and that the client
> would use that data, and the templates, to re-render the page.


first advice when discussing things on the internet:  don't take it personal.

I think that Enrique means that having "the same" template language is
a non-goal.  the "cognitive burden" of two languages is not so heavy;
and since these two environments are so different, there would be
different considerations that make some features unpractical on one
side or the other; or maybe some choice could be "the best" on one and
too awkward or badly supported on the other.

personally, i mostly agree: i do use templating on JS, and it doesn't
look at all like Django templates.  That means sometimes i render some
things in the server, other things in the front end, and a few things
(very few) on both, leading to mostly duplicate code.  would it be
nice to have some code that works equally well on either side? yes,
but it's a relatively small gain.

if "using the same language" was so important, we would all be using node.js...

-- 
Javier

-- 
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 django-developers+unsubscr...@googlegroups.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/CAFkDaoSOYOoyX0w_m0ERzhiJmVPXWGr6pB29AongesG43gOw1w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

[Javier Guerra Giraldez]

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
allows a single request to be passed from one handler (a Django view)
to another (the SSE process).  it might be easier if you use an URL
that goes directly to the SSE process and isn't touched by Django, but
then you need some kind of router, or 'outer url dispatcher'.  unless
the SSE requests can be at a different port from the start? in that
case, the SSE process will need its own URL dispatcher.


> Also, I don't think you would need to mix redis (or any other persistent
> storage) into this. The connected clients could simply be stored in an
> in-memory array, that is discarded if the server crashes. When the server is
> started again the clients will automatically connect again, and the list of
> clients would be built up again.

in-memory as a Python object? but i think the SSE handler must be a
different interpreter instance... unless it's a thread... not sure if
the GIL would be an issue... or an "external" in-memory table? well,
that's what Redis is.


-- 
Javier

-- 
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 django-developers+unsubscr...@googlegroups.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/CAFkDaoSdpgtOheLeyKB_EQAvA5y_peFGCdWNFBZW1xx0XedMTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

[Javier Guerra Giraldez]

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 it support sending messages to a specific subscriber
(or subset of subscribers)?

maybe the easiest way would be to set some variable either in the
router or in the app view function and use it as part of the redis
pubsub channel name.

-- 
Javier

-- 
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 django-developers+unsubscr...@googlegroups.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/CAFkDaoRZGi%3DVTk5_W%3Dk%3DWGcZ8zu%2BUyOnZwjLF4rWvpWV0QknVw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

[Javier Guerra Giraldez]

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 features, it would just be
> a way to send messages to connected clients.


take a look on how it's done with uWSGI: [1].  Basically, the http
request arrives to a Django view in the normal way; then it generates
a response with a custom header, which the uWSGI system recognizes
(much like X-Sendfile), and routes the request to a gevent-based wsgi
app that uses an sse package (probably [2]) to keep the connection.

in the given example, there's no further communication between Django
and the SSE process, but the author then comments it could be done
either with the uWSGI caching framework, or via Redis.

If I were to implement this today (and in fact, i have an application
that might need this in the near future), i would use basically this
scheme (as I'm using uWSGI for all my deployments), and Redis.  The
SSE process would keep in Redis the current set of connected users,
and the Django process would send messages via Redis to the SSE
process.  Of course, not only 'broadcast' messages to every connected
user, but user-specific messages too.

I don't see how would i do it for a reusable app, since it looks most
of the code would run 'outside' Django.  Doing it for the Django core
seems even more problematic, since it would also have to be much more
flexible in requirements, both for the WSGI container (does mod_wsgi
support async python code?  i guess gunicorn does), and also for the
communications between the 'main' Django views and the SSE part.
(probably the cache API would be appropriate)



[1]: 
https://uwsgi-docs.readthedocs.org/en/latest/articles/OffloadingWebsocketsAndSSE.html
[2]: https://github.com/niwinz/sse

-- 
Javier

-- 
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 django-developers+unsubscr...@googlegroups.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/CAFkDaoSSZGZcPsNEomS5%2BPnSAVP6LLmbEcSO5Epu01t6UsxKXg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Remove autogenerated 'id' when using existing database

[Javier Guerra Giraldez]

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 Django won't add an 'id' field.

-- 
Javier

-- 
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 django-developers+unsubscr...@googlegroups.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/CAFkDaoR_r4CnwE58TVcvFPtcD2PXtzFeVKzzKdnXKVzA0DjafQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Javier Guerra Giraldez]

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 above
> pseudo code would be about the same (or sufficiently small as to be
> ignorable)...


i'm sure it's far from ignorable.  .update() generates an UPDATE
... WHERE ... statement, not specifying each record to be updated,
just the criteria to let the DB engine choose them.  Also, the new
field content is either a constant or specified as a function of other
fields (when using F() objects); again, not specified individually,
but let to the DB engine to work it out.

in sum, it's a _lot_ less data to prepare, send, and interpret and
uses a heavily optimized, totally SQL statement.  Not having it would
be a big missing feature.

-- 
Javier

-- 
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 django-developers+unsubscr...@googlegroups.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/CAFkDaoQi3z62emT4Dk1hAvpM5sSUshbFSoOqumA0kZymLURO9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Javier Guerra Giraldez]

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, container__in=flagged_containers). Not a
> problem as long as your query doesn't grow too large for your DB (that is,
> too many containers that might be considered)


i guess Items.objects.filter(current=True,
container__in=Container.objects.filter(item__previous__isnull=True,
item__flag=True)) would be better, it gives the the opportunity to not
get the container list in Python.

... and this is more appropriate on django-users

-- 
Javier

-- 
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 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/CAFkDaoROfS14GrKPb-7XbSTGxyb8g1hNBvZSFDQhSzwTEq7DOg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Javier Guerra Giraldez]

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. Django 1.6 produces the following SQL for
> this query:


what purpose does the "container__item__previous__isnull=True"
argument serve here?  i think it means "an item that belongs to a
container that has an item with no 'previous'", which if it's a linked
list, then any non-empty container would comply, and since you start
the query from the item, then the container is non-empty by
definition.

btw, a linked list in a database?  can you elaborate on that idea?

-- 
Javier

-- 
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 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/CAFkDaoR6GwBq2r68V7HbHhCnjednpL7GBGA1rpOOeru15Wr_%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM support for NoSql databases

[Javier Guerra Giraldez]

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 users make a more
> explicit choice whether to use the ODM API vs the ORM API.

I think it would be very straightforward to do that at the public API
level, but the ModelForm and the admin use lots of undocumented _meta
fields which would have to be mimicked too.

Still, i'm convinced that this would be the best answer, and a formal
definition of _meta is a big plus, maybe even proportional to the
effort needed.


-- 
Javier

-- 
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 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/CAFkDaoTG_hda%3D05FkQgvFFDzbjshKOjzCii9Mi7UtTw652KFPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django ORM support for NoSql databases

[Javier Guerra Giraldez]

On Tue, Dec 17, 2013 at 12:16 PM, Aymeric Augustin
<aymeric.augus...@polytechnique.org> wrote:
> Django’s ORM is entirely designed to translate between an object oriented API 
> and SQL. That’s what its name says. It achieves this through roughly five 
> layers that bride the abstraction gap.
>
> Django’s ORM is fundamentally tied to SQL. It isn’t a choice, a policy or a 
> wish. It’s a fact.


hum  i think you know more than anybody about the ORM, but
recently (March 26) i said something similar on the Django-users list,
just to be immediately corrected by Russel:



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> wrote:
>> > I was wondering if there there was a plan to change Django's ORM to
>> > support NoSQL databases?
>>
>>
>> since there's no such thing as "common NoSQL features", each datastore
>> would need its own modifications, so i think the common attitude is
>> that most of these features don't belong in the ORM.
>
>
> I'm not sure where you've got that impression. Django's ORM was
> *specifically* designed in a way to allow for NoSQL backends. Look at the
> architecture of the django.db module -- there's a query module, and a sql
> submodule. There's very little SQL content in the base query module. That's
> so that we can add a "noSQL" module at some later date. We've also been
> aggressive about adding SQL-specific features (e.g., HAVING clauses, GROUP
> BY clauses) to the ORM API.


so, now i don't really know if Django ORM is appropriate for NoSQL or not.

still, IMHO, the important point is about the wide variety of NoSQL
databases.  as i said before, that's a term just as precise as
"non-elephant animals".

what most people really want when they ask for NoSQL support is to
handle document-based stores, which are mostly just key-value stores
with some introspection to maintain indexes and a little server-side
operations.

honestly, I think it would be better done as a separate library,
different from the ORM, with an API to do queries and return iterable
objects with fields as element properties.  that's enough to be usable
from the templates exactly like querysets.  maybe there could be also
another 'model-like' layer to add more functionality on top of the
persistence layer, but unlike current models, they wouldn't define a
database schema

-- 
Javier

-- 
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 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/CAFkDaoSFUH0TF%3DchSaDQU%3DWxAncFjJwQiR2cY5D5V2JQxvxkJg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: BCrypt and PBKDF2 Password Hash Caching

[Javier Guerra Giraldez]

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 expert)

but still you get only SHA1-level strength, when the whole idea was to
switch to stronger crypto.  if in your case SHA1 is enough, you can
simply keep using it.  if it's not enough, then you shouldn't be using
it.

of course, that's easy for me to say; i don't manage a big site like
yours, so the switch to PBKDF2 doesn't cost me a cent.

i wonder if siphash is strong enough for paswords...

-- 
Javier

-- 
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 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/CAFkDaoSRRWFq6zNmYMtSOzPeTuoRQFN7ZbF72f5xeLda%3DQSG%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: BCrypt and PBKDF2 Password Hash Caching

[Javier Guerra Giraldez]

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 user database and _a_single_one of these cache entries.
the paswords are bcrypt, but the salts are cleartext.  the attacker
chooses _any_ user and calculates a password such that when
concatenated with that user's salt produces a collision [1] with the
single SHA1 cache key stolen.

in short, this library reduces the security from bcrypt to salted
SHA1, and the data needed for any and all the users to any single
cache entry.

hum i don't like it

[1]https://www.schneier.com/blog/archives/2005/02/sha1_broken.html


-- 
Javier

-- 
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 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/CAFkDaoQxxDF8wXVKQ0C2JG6KSD3DSS8u2yXBmh7mXc_roRA8UQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

[Javier Guerra Giraldez]

disclaimer: i'm in no way opposing the deprecation of request.REQUEST.
 still, i feel there are lots of bad reasons in PHP-land about
discouraging use of that feature (typically some imagined security
reasons). I'd like to see some good reasons besides aesthetics (yes,
it's ugly) and duplication 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 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 the request.  the only difference i see is
>> about encoding.
>
> Because they're sent different ways.  POST variables in the request
> body, and GET parameters are in the URL.


same origin: the browser or any http client

same destination: the web app

same transport: the http request

encoded in different parts of the request (body vs url).

yes, they're different, but is there any value in emphasizing the difference?


-- 
Javier

-- 
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 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/CAFkDaoRgoDbLr4WEc43w%3DRc8yBMG%2B66LDkMFx_F95vJQyLELGw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

[Javier Guerra Giraldez]

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 the request.  the only difference i see is
about encoding.

-- 
Javier

-- 
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 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/CAFkDaoRneuFj3y_N7hDtgDohygeuQM3e0w42-gN7gtqArhADUw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Thinking about NoSQL support

[Javier Guerra Giraldez]

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, spatial...

the "common subset" is almost an empty set unless you do it for each category.

still, some of these are on a category of its own, reducing the point
of an abstraction layer. (Redis anyone?)

> However, if you'd rather build an Object Document Mapper [ODM] to provide a
> consistent API for document databases, that could have some value.

An ODM with adaptors for MongoDB, CouchDB, maybe Cassandra (and even
PostgreSQL, which does a far-better-than-average work on this space)
could certainly be welcomed.

> 
> I wish people would stop abusing the term "NoSQL".  Your target concept is
> Non-Relational data stores, not SQL itself.  There's a whole bunch of
> relational stores that don't use SQL, one of them is even called NoSQL!)
> 

to me, "Non-Relational data stores" still sounds as precise as
"non-elephant animals". barely better than NoSQL.

I prefer to call each category by name.  in this case, "document-based storage".


-- 
Javier

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Javier Guerra Giraldez]

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 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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Javier Guerra Giraldez]

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 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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Javier Guerra Giraldez]

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 is only
> one blocking call accepted, which selects events from all connections.
> Typically this call is select(), epoll() or kqueue() depending on the
> system. **Other blocking calls must not be used because they would block the
> entire server until they return, preventing all available processing for
> other connections and thus killing server performance**. Therefore,
> asynchronous programming impose additional restrictions to the programmer,
> like:


this is mostly right; but python, being a high level language, leaves
a lot of space to change things.

greenlets, gevents and eventles take advantage of that, monkepatching
several crucial parts of the standard library, making it
asynchronous-friendly.  in the end, reasonably good code becomes
mostly good for an asynchronous sever.

That's what happens when you run use gunicorn to run Django, which is
a very popular option (and isn't bad at all).  An asynchronous
FCGI-WSGI tool could have a similar performance without any changes in
Django.

in fact, i still think that maybe (just maybe) the easiest would be to
replace the HTTP parser in gunicorn with an FCGI one, keeping all the
asynchronous structure and WSGI handling code.

--
Javier

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Javier Guerra Giraldez]

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 people like to use gunicorn for http-wsgi, if it (or
something similar: flask? wep.py?, werkzeug?) supports fcgi, it could
be the recommended fcgi solution.


--
Javier

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Javier Guerra Giraldez]

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 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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Ability to save 4xx messages to database

[Javier Guerra Giraldez]

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 instance,
it makes sense to centralize logging (not only 404s).  but in that
cases, the most valuable time is that inside the request-response
cycle.  so as soon as the django app has gathered all the loggable
info, it should send to something else.  as mentioned, a good option
is sending via rsyslog to a central logger system.

in short: logging and monitoring are better left to logging and
monitoring systems.


--
Javier

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Ability to save 4xx messages to database

[Javier Guerra Giraldez]

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 centralizing rsyslogd. i've seen
some examples of using Redis to store these.


--
Javier

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Enhance class Storage with additional methods

[Javier Guerra Giraldez]

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 among them.

--
Javier

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Javier Guerra Giraldez]

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

http://www.drdobbs.com/database/full-text-search-with-innodb/231902587

--
Javier

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Javier Guerra Giraldez]

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 windows".

what a pity.

-- 
Javier

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Javier Guerra Giraldez]

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, and postgres.
> I have also personally used it to get data from IBM DB2, an Active Directory
> server, and a .csv file.  If some idiot has written an odbc driver for it, I
> will let you read it from Python.


nice.

does the client run on non-win32 plaforms?  from a cursory read of the
website, adodbapi seems to require pywin32.

-- 
Javier

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Javier Guerra Giraldez]

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.

-- 
Javier

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Switch to database-level autocommit

[Javier Guerra Giraldez]

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 that modifies the database?
 i could live with that...

still, the "set and forget" nature of TransactionMiddleware is very attractive.


--
Javier

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Switch to database-level autocommit

[Javier Guerra Giraldez]

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
TransactionMiddleware does).

this is the default on a few other frameworks i use, and has already
saved my behinds more than once.


-- 
Javier

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Javier Guerra Giraldez]

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 evaluated, but you know that it will be at some point,
then using some_query_set.exists() will do more overall work (one
query for the existence check plus an extra one to later retrieve the
results) than simply using bool(some_query_set), which retrieves the
results and then checks if any were returned."

[https://docs.djangoproject.com/en/1.4/ref/models/querysets/#django.db.models.query.QuerySet.exists]


--
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Improved ajax support idea

[Javier Guerra Giraldez]

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 to
construct them in the client.  check the HATEOAS principle.

http://www.slideshare.net/trilancer/why-hateoas-1547275



--
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Custom ForeignKey which does not require referential integrity?

[Javier Guerra Giraldez]

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 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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Javier Guerra Giraldez]

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
> fires anytime a model instance is instantiated, even if no database
> query or database change occurred.

i think this is the semantic issue that should be explicit:

if those signals are for _every_ model, then should fire for abstract
parents and abstract children (proxy models).

maybe a 'fire_signals' meta option that defaults to False on abstract
parents and True on proxy (and normal) models?

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Javier Guerra Giraldez]

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, deletion should fire one signal,
for the child record; unless the parent overrides the delete() method
and chooses to send a custom signal

proxy: there's no child table.  kind of an 'abstract child', instead
of 'abstract parent'.  deletion should fire one signal, for the
_parent_ record (which is the only real record), unless the child
overrides the delete() method and chooses to send a custom signal.


IOW, i think the existing signals are database-related and should be
fired only for the concrete part(s).  if the abstract part wants to,
it can send custom signals.


second idea:

define three different signals: one for concrete members, one for
abstract, and one for both.

- non-inheritance deletion:
- send concrete-deleted and common-deleted

- concrete inheritance deletion (both are concrete):
- child: concrete-deleted and common-deleted
- parent: concrete-deleted and common-deleted

- abstract inheritance (parent is abstract):
- child: concrete-deleted and common-deleted
- parent: abstract-deleted and common-deleted

- proxy inheritance (child is abstract):
- child: abstract-deleted and common-deleted
- parent: concrete-deleted and common-deleted

but i think that's overkill

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: MySQL connection pooling - preferred method??

[Javier Guerra Giraldez]

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 again.

what about not closing the connections, but aborting any pending transaction?

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GSoC 2012 Proposal

[Javier Guerra Giraldez]

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 docs:

"Django template system is not simply Python embedded into HTML. This
is by design: the template system is meant to express presentation,
not program logic."


in other words, the Django designers considered about embedding Python
and decided against it.


-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Speeding up tests

[Javier Guerra Giraldez]

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
> speed of the test suite (on sqlite3) from 1700 seconds to around 500
> seconds. On postgresql I reduced the run time from 5000 to 2500
> seconds.

doesn't 2 (model validation) and 3 (fixture loading) get skipped when
using SQLite?


-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: queryset caching note in docs

[Javier Guerra Giraldez]

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 on the client side, or if the
> output is sent to a screen on which the user may type a ^S (stop
> scroll). This ties up the server and prevent other threads from
> updating any tables from which the data is being fetched.
> """

this seems to be the case with MyISAM tables; on the InnoDB engine
docs, it says that SELECT statements don't set any lock, since it
reads from a snapshot of the table.

on MyISAM, there are (clumsy) workarounds by forcing the use of
scratch tables, explicitly copying to temporary tables, or buffering
the output.

"""
SELECT ... FROM is a consistent read, reading a snapshot of the
database and setting no locks unless the transaction isolation level
is set to SERIALIZABLE. For SERIALIZABLE level, the search sets shared
next-key locks on the index records it encounters.
"""
(http://dev.mysql.com/doc/refman/5.0/en/innodb-locks-set.html)


-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Javier Guerra Giraldez]

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 different manner. There is no 'correct' way of doing this, and
> trying to find a correct way inside of django itself will only lead to
> constant bike-shed discussions.

absolutely.

I myself deploy Django apps in at least three different ways, each one
for different situations.  choosing any one as _the_ official, and
replacing the others would be a downgrade for most cases.

of course, it could be done; it might even be easier for me. but it's
not what i've chosen.

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Sane defaults for Startapp and Startproject

[Javier Guerra Giraldez]

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 specific.


> in ./newproj/settings.py..
>
> import os
> TEMPLATE_DIRS = (
>    os.path.join(os.path.dirname(__file__), 'templates'),
> )

+0

i use something similar.  i don't like exactly this version, but
getting away from static absolute paths is always good


> and at the end, the commonly used from local settings import * block.

-1

there are too many flavors of that.


> I'd also suggest that django-admin.py startproject newapp, if
> possible, add the new application to the settings.py file if it can be
> done so safely.

-1

once the default settings.py is generated, it's my own; i don't want
any 'help process' meddling with it.


> I would also suggest that when making a new application, the most
> commonly used imports are already there in the py files
> (render_to_response, HttpResonse, get_object_or_404, etc).

0

i like the error messages when i don't include things.

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature request prop for django db cache extention

[Javier Guerra Giraldez]

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 and easier to
distribute (if you have a different INCR for each object, it should
naturally fall on different shards)

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Javier Guerra Giraldez]

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 as a Node._prefix() method that calls a
freestanding _prefix(t,pfx), and moved the relfield=Q smarts to the Q
constructor.

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Javier Guerra Giraldez]

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 free function and
an instance method on tree.Node that just calls it.

> While I'm not sold on the method name (perhaps prefix() or shift() or even 
> __rshift__() would be clearer), I believe the ability to modify Q objects 
> outside of filter()-Expressions is important.

__rshift__() is too C++ for my taste :-)  but I see the motivation.

> Just like &, |, and ~, adding a prefix is an operation on Q objects. And the 
> API should provide a way to manipulate them fully outside of QuerySets.
>
> As an afterthought: The cleanest solution would probably be an implementation 
> in Q.__init__.
> The .push() method would then be unnecessary, as you could write 
> Q(foo=Q(...)) instead of Q(..).push('foo').
> And .filter()/.exclude() would just work, as they simply pass their arguments 
> through to Q.__init__.

yes, that sounds cleaner.  i'm still not sure if that should be on Q
or on tree.Node.

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Javier Guerra Giraldez]

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]

[1]:https://code.djangoproject.com/ticket/16979

really untested, but a variation that doesn't modify core seems to
work well (but the API is far too ugly to share)

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Semantics when calling select_related repeatedly

[Javier Guerra Giraldez]

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 django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: "universal" view decorators

[Javier Guerra Giraldez]

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
> over because I had to jump from class to class to class to explain how it
> all hung together.

that is my own reaction too when trying to see where in the code is
everything that i knew from the old generic view functions.

mixins are a great way to encapsulate specific, well defined behavior;
but tracing the code is a real chore, even so clean code as Django's.
I guess that when you know by heart exactly what does each one do,
they become a pleasure to use.

So, my two cents: please do the documentation first.  once there's a
single place to find exactly what the purpose, mechanism and span of
each one, then adding more would be welcomed.


-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Logging all/slow queries

[Javier Guerra Giraldez]

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 context.  for
example, there are some views that have to finish quickly, and others
that could take longer.  the database logs don't discriminate between
those, so it's not easy to see which queries are more important to
optimize.

and of course, it's not always easy to know which ORM produced which
SQL.  knowing which Python code produced each SQL means a lot less
guesswork.

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Javier Guerra Giraldez]

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 large
>> tables are much faster:
>
> are they?    hashtables shouldn't be too sensitive to key size, as
> long as the string size stays bounded... like on IP addresses (max 15
> chars)

OTOH, for really huge database tables, making the index 4 times
smaller can be a significant difference on RAM-starved servers
but to fill 1G can hold something like of 50million IP addresses in
text form...

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Javier Guerra Giraldez]

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 string size stays bounded... like on IP addresses (max 15
chars)

of course, i don't know about the specific dict implementation on
Python.  Sounds like a job for a microbenchmark!

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Conditional aggregations.

[Javier Guerra Giraldez]

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 adapt to local dialects almost every time i see some
SQL inside a function, especially on mysql and sqlite.   maybe it's
because of the bad quality of code i tend to see (typically
originating from hand-coded mssql accesses deep within an excel
sheet), but seeing CASE also rings my "i'll need an extra week just
for this" alarm.

then again, i'm s far from being an SQL portability expert.  it's
just something i've (reluctantly) done a few times

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Conditional aggregations.

[Javier Guerra Giraldez]

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
> really_expensive_house, ...
>  FROM house
>  JOIN something on something.id = house.something_id

this looks quite non-portable

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Deprecation policy for IE6

[Javier Guerra Giraldez]

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  pages.
of course, to get them to work on IE6 & 7 i used excanvas.js, which
made a not-so-bad job.  some things were missing, but it was doable.

also, on IE7 i preferred to use 'standards mode', since it made some
CSS and box layouts not as bad as IE6

when IE8 came out, i tried it.  the new 'standards mode' was slightly
more standard CSS and box layouts; but excanvas.js just didn't work.
after some reading, i found that IE8 standards killed VML (the MS
alternative to SVG), which excanvas used to fake the canvas element.

finally, i had to force "IE7-standards mode"  everywhere.  effectively
disabling any IE8 advantage (nothing to weep about, fortunately).

tl;dr;  in my case, IE8 is less useful than IE7

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Deprecation policy for IE6

[Javier Guerra Giraldez]

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 Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: Composite fields API

[Javier Guerra Giraldez]

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 option as there is no field to attach that logic to - now there
> is.

while i'm +1 about using unique on the composite field, i'm -0 about
deprecating unique_together.  there are times when i want to ensure
composite uniqueness but don't consider those fields as part o a
composite.  in those cases, i wouldn't want to define the composite
field just to say its unique.

yes, i know about the Python Zen on "only one obvious way", but in
this case it seems to be two semantically different things (even if
the generated SQL is the same).  for me, readability wins

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: model fields options

[Javier Guerra Giraldez]

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 editable, error_messages:
> these options are not part of the ORM, they are parts of the forms
> subsystem that have somehow ended up in the ORM.  Why should the ORM
> know anything about forms, or any other part of Django for that
> matter?

they're UI things, but forms aren't the only UI imaginable.

and, they're UI things that belong to the field.  not the database
field, but the model field.

-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Use cases for a OneToMany field

[Javier Guerra Giraldez]

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 Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Composite primary keys

[Javier Guerra Giraldez]

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:

the order of the fields on a composite index is determined by the
exact value given to the primary_key argument.

that way, just setting primary_key=True on a few fields won't
guarantee order, but something like:

class City (models.Model):
country = models.CharField (max_length=2, primary_key=1)
state = models.CharField (max_length=2, primary_key=2)
city = models.CharField (max_length=3, primary_key=2)
Name = models.CharField (max_length=20)

would set the (country,state,city) primary key in the obvious order.

in short: giving any non-falsy value to primary_key would add the
field to the key, the exact value would determine ordering.


-- 
Javier

-- 
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, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: How to concatenate strings in django templates?

[Javier Guerra Giraldez]

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" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature request: ForeignKey through parameter

[Javier Guerra Giraldez]

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 what if B has more than one ForeignKey('C') fields?

-- 
Javier

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature request: ForeignKey through parameter

[Javier Guerra Giraldez]

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 = ForeignKey('C', through='B', related_name='a_set')
>
>    class B(Model):
>        c = ForeignKey('C')

i'd love such a feature too, but i think a better syntax could be
something like:

   class A(Model):
   b = ForeignKey('B')
   c = ForeignKey('B__c', related_name='a_set')

   class B(Model):
   c = ForeignKey('C')

where the second part of the reference is the name of the field ('c'
in this example), not the model class ('C')

-- 
Javier

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Javier Guerra Giraldez]

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',
>>>        ('debug_toolbar', {
>>>                'INTERCEPT_REDIRECTS': False,
>>>                'INTERNAL_IPS': ('127.0.0.2',),
>>>        }),
>>>        'django_extensions',
>>>        ('favorites', {
>>>                'fave': ‘pages.models.Page',
>>>        }),
>>>        'comercial',
>>>        'specs',
>>> )
>>>
>>>
>>> and in favorites.models.py:
>>>
>>>  class Favorite(models.Model):
>>>      item = LazyForeignKey(args[‘fave’])
>>>      user = ForeignKey(User)
>>>      date = DateTimeField(default=utcnow)
>>>
>
> So how does this work?  Where do args come from?

args (for lack of a better name) is the same dictionary passed as the
second part of the tuple in the INSTALLED_APPS list.

when Django loads each app, if the entry in INSTALLED_APPS is a tuple,
the first member is the app name, and the second one is made available
to the app as 'args'.


((erratum: in this case, we don't need any 'LazyForeignKey', the usual
'ForeignKey' works:

  class Favorite(models.Model):
  item = ForeignKey(args[‘fave’])
  user = ForeignKey(User)
  date = DateTimeField(default=utcnow)

))


-- 
Javier

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Javier Guerra Giraldez]

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 parameter.

> Configurable apps were the subject of Arthur Koziel's GSoC project
> this year. From my conversations with Jannis this week at DjangoCon,
> it sounds like this GSoC code is in pretty good shape. However, in
> order to smooth the path, we will probably end up landing some
> preliminary work for 1.3, and land the final patch for 1.4.

yes, i've just seen the link posted by Yuri.  maybe GSoC projects
could use some more visiblity, a Git fork of the whole Django code
doesn't make it easy to know what's happening there.

judging just from the GSoC proposal, an app object could make a lot of
OOP goodness available.

> The LazyForeignKey pattern has been proposed by a number of parties;
> it's an interesting idea that is worth some serious consideration.
> There are some issues with implementation (e.g., exactly how to
> describe the relationship in a clean way that doesn't require us to
> import settings in order to define models), but these issues shouldn't
> be too hard to sort out. I'll see if I can get some discussion going
> at the sprints over the next couple of days.

it all that really necessary? i'd think that just not using hardcoded
constants for the model class or name buys a _lot_ of flexibility.

of course, that's easily doable right now.  the simplest case would be
just using settings variables:

in settings.py:

  FAVORITES_FAVE_MODEL=‘pages.models.Page'

in favorites/models.py:

  class Favorite(models.Model):
  item = ForeignKey(settings.FAVORITES_FAVE_MODEL)
  user = ForeignKey(User)
  date = DateTimeField(default=utcnow)


but that's just ugly, and pollutes a global namespace.  hence,
configurable apps :-)


-- 
Javier

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Javier Guerra Giraldez]

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 relationships; but don't think this
solution is particularly elegant, nor flexible enough.

what about giving parameters to the apps?  something like:

INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.admin',
('debug_toolbar', {
'INTERCEPT_REDIRECTS': False,
'INTERNAL_IPS': ('127.0.0.2',),
}),
'django_extensions',
('favorites', {
'fave': ‘pages.models.Page',
}),
'comercial',
'specs',
)


and in favorites.models.py:

  class Favorite(models.Model):
  item = LazyForeignKey(args[‘fave’])
  user = ForeignKey(User)
  date = DateTimeField(default=utcnow)


this helps to reduce global settings pollution, simply by binding a
global ('args' in this example) to the respective app's parameter
dictionary.

it could even allow a project to import a single app twice with
different parameters:

INSTALLED_APPS = (
...
('favoritebooks', {
'APP_MODULE': 'favorites',
'fave': ‘pages.models.Book',
}),
('favoritepages', {
'APP_MODULE': 'favorites',
'fave': ‘pages.models.Page',
}),
'comercial',
'specs',
)

here, APP_MODULE tells Django where to import the app from, by default
it would be the app name (as now), but specifying it separately allows
the user to give a different name to the app in the project's context.

toughts?

-- 
Javier

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Revised form rendering

[Javier Guerra Giraldez]

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 could import each one separately (or maybe several included
>> by default).  in my example, left_table would inherit from as_table,
>> simplifying the implementation.  the {%form%} syntax wouldn't be a
>> parameter to a single renderer, it's a selector to choose which
>> renderer to use.
>
> I'm not sure I understand.
>
> In my proposal, {% load custom_form %} loads a single form template
> tag. That template tag implements a single specific rendering scheme.
> You import library X, you get library X's layout. If you want a
> different layout, you import a different library (namespaces being one
> way to get around the 'multiple layouts in a single )

i didn't think too much about namespaces; maybe that's a cleaner
solution than my proposal.


> How are you getting your "as_p" renderer into your template? How is it
> made available to the {% form %} tag as an argument? How does the
> "selector" determine what is available for selection? What defines the
> default behavior of {% form %} in the first place?

what i think is:  currently, the form system has a few renderers as
class methods.  the new system would factorize them out as classes.
for this, it would expose a small API, so that the user could easily
write new renderers, ideally even supporting inheritance to make it
easier to just modify existing renderers.

a new renderer class would have to be registered with the form system,
just like a new template tag has to be registered with the template
system.  this might be at app loading, or more likely, with {%load%}
tags on the template.  you could {%load%} as many renderers you want,
since they don't overwrite any behavior, they don't define a new
{%form%} tag.

the {% form %} tag is provided by the form system, not by the
renderers.  there are a few 'included' renderers, which probably you
don't have to load, (just like you don't have to load the standard
template tags).  one of these would be the default (just like the
current form system has a default of as_table() )

a parameter to the {%form%} tag (or a subtag, on André's proposal)
would be the 'selector' to choose between the registered renderers.
again, the renderer doesn't override the {%form%} tag; it's the tag
the one that chooses the selected renderer.

-- 
Javier

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Revised form rendering

[Javier Guerra Giraldez]

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.  see my answer to André for an idea on this

>  * Composibility. If I understand your intention, a form library would
> need to provide all the layout schemes that you want to have available
> on a page. That means if you wanted "P" and "UL" forms on the same
> page, you would need to define a combined "P & UL" form library. This
> sort of composition doesn't strike me as a desirable goal.

no, the P, UL (and my hypothetical left_table) would each one be a
class; you could import each one separately (or maybe several included
by default).  in my example, left_table would inherit from as_table,
simplifying the implementation.  the {%form%} syntax wouldn't be a
parameter to a single renderer, it's a selector to choose which
renderer to use.

-- 
Javier

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Revised form rendering

[Javier Guerra Giraldez]

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 chain of
parameters of filters on a single tag.

> I see this as having several advantages:
>
> 1) It introduces a clearer way of laying out settings.
> 2) It leverages the template engine for specifying defaults in a
> simple but ingenious way:
> {% form myform %}
>    {% include "form_settings.django" %}
> {% endform %}
> -- form_settings.django:
>    {% doctype xhtml1 %}
>    {% replace_widget datetime=calendar %}


personally, i don't think this is a nice solution.  {%include%}'ing a
set of settings is not a default, it's a packaged setting.

i like better to define a python form of the same; IOW document a
mapping, so that your first example would be equivalent to:

myform.render ({
  'birthday_widget':'calendar',
  'renderer': "as_ul",
  'autocomplete': "name_autocomplete",
  'doctype': "xhtml1"
})

or:

myform.render (birthday_widget='calendar', renderer="as_ul",
autocomplete="name_autocomplete", doctype="xhtml1")


and allow the use of either of these syntaxes in settings.py, form
definition or context processors to set defaults.




-- 
Javier

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Revised form rendering

[Javier Guerra Giraldez]

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' rendering would mean:
>>
>> {% load xhtml_p_forms %}
>> {% form myform %}
>
> Just a personal feedback, to me the rendering strategy is related to a whole 
> project and should be defined in settings, it's too easy to forget a loading 
> in a template. I know that you can use the django.template.add_to_builtins 
> function but it in this case it should be documented.


i'd say the other way around; it's not hard to imagine a single page
with two or three forms rendered with different styles: a 'main' one
rendered as_table(), and a footer field rendered as_p().  in that
case, {%load%}'ing the style is too coarse granularity.  i'd prefer an
optional parameter to {%form%} to choose the renderer.

something like:

class myformrenderer (forms.as_table):
  name = 'left_table'
  ..

and in the template you could say {% form myform:"left_table" %}

>> Doctypes
>> 
>>
>> Once these two changes are in place, we use the form template tag
>> specify the doctype that is passed to the widget render call. A
>> 'html5_p_forms' library will pass 'html5' as the doctype when
>> rendering fields, and get HTML5-compliant form fields; the
>> 'xhml1_p_forms' library will pass 'xhtml1', and get XHMTL1-compliant
>> form fields.
> Again, why not directly in settings in order to be project's specific? Is 
> there anybody mixing doctypes on the same website? (backward compatibility 
> maybe?)


here i fully agree, doctype should be project-specific.



-- 
Javier

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: natural keys and dumpdata

[Javier Guerra Giraldez]

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 object so this should be possible.


the best solution isn't natural keys (which are so very seldom a good
idea); what you need is UUIDs.

there are a couple of wontfix'd tickets on this theme, mostly because
the feeling that this doesn't belong to core when it can easily be
added by a custom fieldclass.

two implementations:

http://djangosnippets.org/snippets/1262/
http://www.davidcramer.net/code/420/improved-uuidfield-in-django.html


-- 
Javier

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Imports in the tutorial

[Javier Guerra Giraldez]

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.
>>
>
> Explicitness is good. I like being explicit, that's one of the reasons I
> love Python. But I'd argue that having to separate installations of the same
> app because they _have_ to have the same package name involves more python
> path mucking around than just installing them on the global path with
> different names.


there's a difference between being explicit and introducing unneeded
dependencies.

-- 
Javier

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: {% include_partial %} template tag

[Javier Guerra Giraldez]

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 bit non-obvious to me.

what about:

{% include "some/template.html" with foo=bar baz=spam %}
=> adds varaibles 'foo' and 'baz' to current context

{% include "some/template.html" withonly foo=bar baz=spam %}
=> replaces current context with one having just 'foo' and 'baz'

-- 
Javier

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: NoSQL Support for the ORM

[Javier Guerra Giraldez]

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
>> missing the point.
>
> Then you're calling everyone a fool. :) What do you call a CouchDB or
> Cassandra index mapping usernames to user pks? Its purpose it exactly
> to do something that relational DBs provides out-of-the-box. You can't
> deny that people do in fact manually maintain such indexes.


I think there are two very different goals; maybe opposite, maybe complementary:

A: use the _same_ ORM with NoSQL backends.  then it's important to
provide (almos) every capability of the current ORM, even if they have
to be emulated when the backend doesn't provide it natively.

B: create a new ORM-like facilty for NoSQL (lets call it ONoM).  it
would be used mostly the same as the ORM; but with different
performance properties, and some capabilities missing, some others
added, and some available but with 'emulation warnings'.  but in the
end, they should return queryset-like objects, that _must_ be usable
by existing code that take querysets.


IMHO, if the choice between these two isn't make clear and explicit at
start, this kind of arguments won't end.

-- 
Javier

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.