Re: NoSQL support
On Apr 28, 2:36 am, "Jonas H." 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: jQuery.tmpl() and Django
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: auth.user refactor: the profile aproach
I completely agree with Adrian's proposal, with these amendments suggested by Russell in order to build something slightly more generic, like LazyForeignKey, instead of UserField. In fact, a UserField coud end up being provided as a subclass of LazyForeignKey with a default name provided (e.g. 'user') and any other user-domain-specific customizations needed. Thanks, Eric Florenzano > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/h1uVd02e7owJ. 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: Database pooling vs. persistent connections
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: WTForm should be inbuilt to Django, and make admin & others use it.
If anyone else read this and was as confused as I was at first, make sure to note that this is different than WTForms[1], which is an alternate form library that took several of its cues from Django's newforms. [1] http://wtforms.simplecodes.com/ 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
> 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 -~--~~~~--~~--~--~---
Re: Proposal: enable CSRF middleware by default
> 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: #9282 (comment moderation features) and Akismet removal
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 for 1.2: built-in logging with django.core.log
On Sep 17, 1:25 am, Simon Willison 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: Adding signing (and signed cookies) to Django core
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: Model.objects.raw() (#11863)
> 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: Proposal: Tutorial Refresh
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 -~--~~~~--~~--~--~---