Re: Explicit default managers?
http://code.djangoproject.com/ticket/9676 created to track this. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
How to use variables from settings.py and django session in Jinja2?
Hi there, I tried to integrate Jinja2 with Django, and it is pretty straightforward actually. But I didn't figure out how to access these settings.py variables (django specific) and the django session in the Jinja2 template. Could somebody help me out? Thanks a lot! cheers, Honghai --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
How to use variables from settings.py and django session in Jinja2?
Hi there, I tried to integrate Jinja2 with Django, and it is pretty straightforward actually. But I didn't figure out how to access these settings.py variables (django specific) and the django session in the Jinja2 template. Could somebody help me out? Thanks a lot! cheers, Honghai --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: How to use variables from settings.py and django session in Jinja2?
Please ask on the django-users mailing list. This one is for development of Django itself, not usage questions. Karen --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Denormalisation Magic, Round Two
I think it would be even nicer if the function passed into the decorator could actualy return the new value of the field, instead of assigning it and call save(). Currenty the function does two tasks: 1) figure out what needs to be updated "resolve dependenys" 2) calculate the new value maybe the first task could be implemented in such a generic way, that it fits most cases. Maybe something like a DependencyResolver class that has a method witch takes an instance (the one beeing saved) and returns a queryset (instances that need to be updated. this could result in a syntax like this: @denormalized(models.TextField,blank=True,depend= ['self',DirectForeignKey(Picture)]) def users(): return ', '.join(str(p.owner) for p in self.picture_set.all()) so DirectForeignKey (has DependencyResolver as base class) could look for a FK to Gallery in Picture. this way the most common cases would require very litte code, and if somebody has some very uncommon dependencies he can implement a special resolver. i'll some experimenting on implementing this. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Denormalisation Magic, Round Two
one more thing... On Nov 23, 12:00 pm, Andrew Godwin <[EMAIL PROTECTED]> wrote: > Additionally, your code loops over every model every time, whereas in > some cases you can detect which specific model needs updating (for > example, if you know that the field "planet" on the just-saved object is > a foreign key to your model). i don't think so. if you mean lines 35-38 in fields.py: this is only used to rebuild all denormalized values in the whole DB via the management command, witch means everything needs to be updated. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Ticket 8638: Provide setting to disable e-mail sending
Hi Django Devs, I saw that ticket[1] made it into the 1.1 list and I was drawn to it. I have a project that will be doing some mass sending of emails soon, so I could definitely use something more than what is currently there. Firstly, the title simply says it wants the ability to disable emails, while some of the comments on the ticket are looking for a bit more than simply disabling. Where would we like to take this? In case we headed down the road to trapping and looking at emails that tried to send, I wanted to be a bit smarter about what needs to be done so I poked around the code a bit and did some research. I ended up writing a blog post on what I found[2]. Essentially you can fire up a built-in SMTP server that's already baked into Python, change the port number for your email, and you're trapping emails and can view all headers, etc. If we wanted to add the ability to trap, debug, and view emails that were sent, I have a few ideas I'd like to get feedback on. The ideas are in order of complexity in my mind... 1) Add a management command that launches a mail server. Something similar to runserver, and the user would have to adjust their email settings accordingly... ./manage.py runmailserver localhost:1025 What I like about this is it can be extended or redirected to a file. We can add a --format= option for plain text, mbox format, eml format, or whatever other standard mailbox formats there are. Or possibly even provide a dotted path to the class you want to use in its place, similar to middleware, that gets loaded. This might be useful if you want to log emails to a database... ./manage.py runmailserver 1025 -- class=myproj.mailserver.EmailDatabaseLogger I'm curious if running this should imply that the EMAIL_* settings get hijacked and overridden for as long as the mail server is running. If not, see idea #2. 2) In combination with #1, add a new option to runserver to override the EMAIL_* settings. So you'd run #1 in one console, then something like this in the 2nd: ./manage.py runserver --emailport=1025 This saves the user from having to adjust settings for local development if they're not already set up to do so. But it still requires both commands to have a matching port number, thus... 3) A step up in the automation and involving more discussion... Add another option to runserver to launch a mail server for debugging. This would hijack the mail server settings, launch a local smtp server, and then runserver. All output would be in the same console. I think this idea is a bit limiting considering all the fun stuff you can do with #1. This would be option overload for runserver I think. But it does have the added benefit of running a single command in a single console. ./manage.py runserver --maildebugger Other ideas or thoughts? Thanks, Rob References: [1] http://code.djangoproject.com/ticket/8638 [2] http://rob.cogit8.org/blog/2008/Nov/20/testing-emails-django/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Using pysqlite2 instead of sqlite3 when desired
On Nov 18, 5:15 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Mon, 2008-11-17 at 16:19 -0800, Matthew D. Hancher wrote:
>
> [...]
>
> > Options include:
>
> > A. Leave sqlite3 as the default, and add a configuration setting that
> > forces use of pysqlite2 if desired.
>
> > B. Always try both sqlite3 and pysqlite2, and use whichever has the
> > greater version number if both are present.
>
> > C. Same as B, but with an optional configuration option to force one
> > or the other if desired.
>
> > D. Switch to making pysqlite2 the default, since that's the correct
> > name for the module if the user has explicitly installed it, and treat
> > the Python-bundled version as the fallback.
[...]
> I guess I prefer D the most, subject to a slight concern if the wrong
> version could possibly be imported (but I can't imagine how). Then
> option A. Don't like the others at all.
Well, I think it's actually not so implausible that option D could
cause
someone somewhere a problem. All it would take would be for them
to have an outdated version of pysqlite2 installed on their system.
Django would have been happily ignoring it since r3818, and suddenly
we'd be using it instead. Lord knows how many babies might be killed.
So, if you're not a fan of option B then I'm inclined to go with the
conservative option A. Then the question is, what should the
configuration option look like? Here are two options:
1: SQLITE_MODULE_NAME = 'pysqlite2'
2: DATABASE_OPTIONS = {'module': 'pysqlite2'}
3: USE_PYSQLITE2 = True
4: # Other
Preferences? My current vote is option 2, because it does not
introduce a new top-level setting, but it does sort of overload an
existing one, so I'd understand arguments in favor of option 1.
Matt
Matt Hancher
Intelligent Systems Division
NASA Ames Research Center
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Using pysqlite2 instead of sqlite3 when desired
On Mon, 2008-11-24 at 18:20 -0800, Matt Hancher wrote:
> On Nov 18, 5:15 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > On Mon, 2008-11-17 at 16:19 -0800, Matthew D. Hancher wrote:
> >
> > [...]
> >
> > > Options include:
> >
> > > A. Leave sqlite3 as the default, and add a configuration setting that
> > > forces use of pysqlite2 if desired.
> >
> > > B. Always try both sqlite3 and pysqlite2, and use whichever has the
> > > greater version number if both are present.
> >
> > > C. Same as B, but with an optional configuration option to force one
> > > or the other if desired.
> >
> > > D. Switch to making pysqlite2 the default, since that's the correct
> > > name for the module if the user has explicitly installed it, and treat
> > > the Python-bundled version as the fallback.
>
> [...]
>
> > I guess I prefer D the most, subject to a slight concern if the wrong
> > version could possibly be imported (but I can't imagine how). Then
> > option A. Don't like the others at all.
>
> Well, I think it's actually not so implausible that option D could
> cause
> someone somewhere a problem. All it would take would be for them
> to have an outdated version of pysqlite2 installed on their system.
> Django would have been happily ignoring it since r3818, and suddenly
> we'd be using it instead. Lord knows how many babies might be killed.
This is what I was hinting at (since I have plenty of modules for python
2.3 and 2.4 sitting around), but think about how it can really happen.
SQLite is a binary module. So you will have had to have intentionally
built a binary module of an earlier version of pysqlite2 for a version
of Python that *already contains* sqlite3. You did this by accident,
apparently, since you didn't know it was an earlier version. Is this
really a use-case we need to cater for?
When you upgrade from Python 2.4 to Python 2.5, your pysqlite2 module
for python2.4 is no longer in the game.
Still, it is a minor inconvenience, so I could still sleep at night if
we went with option A. The need to use the pysqlite2 version apparently
affects Windows users of Python 2.5.1 (maybe 2.5.2 also, I don't know),
since there was some version skew there that Ramiro Morales identified
as a problem and people using spatial support. The latter group can
certainly read about the new setting and use it. It's the former group
I'm a little more concerned about. It includes a lot of beginners who
are not famous for their ability to read documentation or debug problems
as a broad group.
> So, if you're not a fan of option B then I'm inclined to go with the
> conservative option A. Then the question is, what should the
> configuration option look like? Here are two options:
>
> 1: SQLITE_MODULE_NAME = 'pysqlite2'
> 2: DATABASE_OPTIONS = {'module': 'pysqlite2'}
> 3: USE_PYSQLITE2 = True
> 4: # Other
>
> Preferences? My current vote is option 2, because it does not
> introduce a new top-level setting, but it does sort of overload an
> existing one, so I'd understand arguments in favor of option 1.
It's a toss-up between options 1 and 2, isn't it? Normally, I'd prefer
option 1, but it adds a bunch of extra files to support essentially one
import statement.
Since so far only you and I have made real input here, I'd like to hear
what any of the other maintainers (or anybody else who uses this stuff)
thinks. Realistically, any of the options are survivable, so barring any
great arguments one way or the other, we should just pick one and commit
it. I don't see the functionality request as being controversial and I'm
probably putting too much effort into worrying about the fine details.
Cheers,
Malcolm
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
