Re: Database pooling vs. persistent connections

[Eric Florenzano]

One question: does this proposal include some way of specifying a maxiumum 
number of outstanding connections to the database from a single process? 
 Looked but didn't see it in the pull request.  In my experience, most 
PostgreSQL instances don't have a whole lot of breathing room in terms of 
the number of total outstanding connections they can handle due to low 
shared memory defaults etc. This is something that django-postgrespool does 
by way of SQLAlchemy's pool_size and max_overflow settings.

-- 
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: jQuery.tmpl() and Django

[Eric Florenzano]

On May 26, 11:59 pm, Jonathan Slenders 
wrote:
> +1 for the verbatim tag. I think this is something that we need in
> Django by default.
>
> But I think that ericflo his implementation is not truly verbatim. I
> mean, that it will probably drop whitespace between "{%" and the tag
> names. It may not be important for jQuery, but if we implement
> verbatim, the output should be an exact copy of the verbatim contents.

This is true.  I couldn't find an easy way to implement a verbatim tag
that was truly "verbatim" at the time without making changes to
Django's internals.

-Eric

-- 
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: NoSQL support

[Eric Florenzano]

On Apr 28, 2:36 am, "Jonas H." <jo...@lophus.org> wrote:
> For anyone who's interested, here's the complete diff of Django-nonrel
> against Django 1.3:http://paste.pocoo.org/show/379546/

Are you sure this diff is correct?  From a quick look over that diff,
it seems there's a bunch of seemingly unrelated changes in there
having to do with password resetting, base64 url encoding, and file
uploading--none of which have to do with NoSQL.

Thanks,
Eric Florenzano

-- 
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: Proposal: Tutorial Refresh

[Eric Florenzano]

I've done this before: http://thisweekindjango.com/screencasts/
( http://github.com/ericflo/startthedark )

I can attest, from the amount of feedback that I've received about
that series of screencasts, that building an entire website from the
ground up is extremely valuable to beginners.  It's also a fairly
massive amount of work.  There's a lot that's changed in the Django
ecosystem since those screencasts, so I'm excited about the prospect
of a fresh new tutorial.

Some lessons I learned along the way:

* Develop the entire site first, and then deconstruct it into the
pieces

My first attempt I didn't do this, and I ended up having to scrap it
and start over after having built the whole site.  This will save you
so many headaches later down the line.

* Actually launch the site somewhere

Last week or so I forgot to renew the startthedark.com domain, and (to
my surprise) I've gotten several e-mails from people about it.  People
apparently really do go to the site itself to see it in action before
watching the screencasts.

* Have the bits and pieces of code in-line with the tutorial, but also
provide a full checkout of the entire site

A lot of what people need to know can be contained in the tutorials,
but what some people need is to actually see the full picture--
everything and how it all fits together, down to the minute details.
This may be less of a problem now with Pinax on the scene, but that
was one major piece of feedback that I had was that people liked being
able to download the whole source tree.

Hrm, I feel like I have more battle scars, but right now I can't think
of anything else.  I'll be around so feel free to ask me any questions
or whatever.

Thanks,
Eric Florenzano
--~--~-~--~~~---~--~~
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.objects.raw() (#11863)

[Eric Florenzano]

> So my question, and this is something I've been thinking about a lot
> of the proposals lately is: why should this be in Django itself.

I couldn't agree with your sentiment more, in the whole.  In fact, to
me, until now all of the proposals aside from Simon's seem better
outside of Django than inside of it.

That being said, this proposal is actually something that I think fits
well within Django core itself, as it really is a logical extension of
the core functionality of the ORM.

Thanks,
Eric Florenzano
--~--~-~--~~~---~--~~
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: Adding signing (and signed cookies) to Django core

[Eric Florenzano]

A big +1 on signed cookies, and I like the direction the discussion is
going.

Also, I hope this doesn't derail this discussion, but I hope after
signed cookies are added, auth can be made to optionally use signed
cookies instead of sessions.

Thanks,
Eric Florenzano
--~--~-~--~~~---~--~~
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: Proposal for 1.2: built-in logging with django.core.log

[Eric Florenzano]

On Sep 17, 1:25 am, Simon Willison <si...@simonwillison.net> wrote:
> 1. We'll be able to de-emphasise the current default "e-mail all
> errors to someone" behaviour, which doesn't scale at all well.

I'm a big fan of this proposal, for exactly this reason.

+1

Thanks,
Eric Florenzano
--~--~-~--~~~---~--~~
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: #9282 (comment moderation features) and Akismet removal

[Eric Florenzano]

The Akismet module seems to me to be similar to a Memcached cache
backend.  Yes, it's coupled to a single implementation, but it's the
canonical implementation--note that the only competitor, TypePad
AntiSpam [1], is "100% Akismet API compatible".

> James, this is something that can be added later. This is progressive
> enhancement of the functionality and *if* (not a given) we take what's
> in #9282 now without blocking on every feature that might be possible or
> popular, it won't be a shame. It isn't a half-baked implementation, it's
> just leaving the door open for more additions in the future.

I don't really understand this argument.  Maybe I'm not parsing it
correctly, but I read this as "Your implementation is good, but let's
not add it now so that we can add it later", which seems a bit
strange.

Thanks,
Eric Florenzano

[1] http://antispam.typepad.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, 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: enable CSRF middleware by default

[Eric Florenzano]

> Too late now since it's already committed, but I've got some serious
> reservations about this one. More development effort should have gone
> into improving and refactoring the middleware before it got
> automatically enabled.

I agree with James here.  With apologies to Luke, the CSRF middleware
needed to be more bulletproof before it was turned on by default.  I
can't count the number of times since turning on the middleware that
I've been greeted with the cryptic "Cross-Site Request Forgery attempt
detected" message inexplicably, and every time I try to go and repeat
it, I am unable to do so.  I suspect that after 1.1 this will be the
most common FAQ/Complaint, is people won't understand and will get
these types of messages often.

Also, I ran into the problem myself where huge swaths of my tests
failed due to the CSRF middleware.  It took me a bit to realize that
it had to do with the CSRF middleware, and if it tripped me up, it's
going to trip up other users as well.  If we're going to ship CSRF
middleware on by default, I propose that we take a second look at the
wontfix status of tickets like #9172.

Thanks,
Eric Florenzano
--~--~-~--~~~---~--~~
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: Multiple Database API proposal

[Eric Florenzano]

> To me replication is a major use-case. I suspect most people who move
> beyond single server setup and beyond 10'000 - 20'000 visitors realize
> that replication should just be in place ensuring performance and
> redundancy. In my experience other multi-DB patterns (those that covered
> with `using()` and Meta-attributes on models) are just *less* common in
> practice. So I consider leaving replication to "time permitting" a mistake.

There's a finite amount of time in GSoC.  If he says he will
definitely do it, then something else will probably have to be cut to
make time.  Everything else, however, is prerequisite to implementing
the actual replication strategies.

There are almost two GSoC projects here, wrapped into one.  First
there's the plumbing in Django's core that just needs to happen.
Second there's the actual APIs built on top of that plumbing.  The
former needs to happen before the latter, but in implementing the
latter, some changes will almost certainly need to be made to the
former as assumptions are challenged and implementation details get in
the way.

In any case, I think Alex is the one to do this.  He's got a +1 from
me (not that it means much now that I'm on Malcolm's special list).
Speaking of Malcolm's special list...

> One suggestion Eric Florenzano had was that we go above and beyond
> just storing the methods and parameters, we don't even excecute them
> at all until absolutely necessary.

I wasn't actually making that suggestion, per se.  I was just thinking
out loud that _if_ this type of system were implemented, then it would
open the door for some fun computer-sciency things like performing
transitive reductions on the operations performed on the QuerySet.
That being said, I'm not convinced it's the right way to go because of
its significant added complexity, and because it would make poking
around at the Query object more difficult and generally make the Query
object more opaque.

Thanks,
Eric Florenzano
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---