Re: Check-in #5 / Multiple timezone support for datetime representation
On Oct 16, 11:48 am, Aymeric Augustin wrote: > Hello, > > I've implemented the storage and retrieval of aware datetime objects in > SQLite. This involved some refactoring, because SQLite returns datetimes as > strings, and I didn't want to duplicate the parsing code. All database > backends are now covered. > Is it worth looking at registering a custom converter for SQLite (http://docs.python.org/library/sqlite3.html#converting-sqlite-values- to-custom-python-types) to handle the date objects? Converters can be registered per-column - the SELECT query would need to be tweaked to hint to the SQLite libs to call the registered converter. I'm not sure if that would be too intrusive to the existing Django query builder. -- 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: Wrong JOIN with nested FKs
Hello,
akaariai has proposed a patch that solves the bug described below.
It is attached to ticket #16715. How do we proceed from here?
Sebastian.
On Thu, 29 Sep 2011 21:52:23 +0200
Sebastian Goll wrote:
> Hello,
>
> I'd like to draw your attention to ticket #16715:
>
> "Wrong JOIN with nested null-able foreign keys"
> https://code.djangoproject.com/ticket/16715
>
>
> It seems that the Django query generator sometimes picks the wrong join type
> in the following situation:
>
> Model A
> | (Relation A/B: null=True)
> v
> Model B
> | (Relation B/C: null=False)
> v
> Model C
>
>
> A priori, the correct/default join for Relation A/B is LEFT OUTER JOIN, while
> the correct join for Relation B/C is INNER JOIN.
>
> However, when combining all three models, the join between Model B and C must
> be promoted to LEFT OUTER JOIN. If we wouldn't do that, instances of Model A
> that do not reference an instance of Model B would be missing in the
> resulting queryset: the INNER JOIN wouldn't be able find the matching Model C
> with a primary key of NULL which results from the join between Models A and B
> for As without referenced Bs.
>
> This promotion works in most cases and is done in
> django/db/models/sql/query.py, methods 'promote_alias' and
> 'promote_alias_chain' of class Query.
>
>
> However, the promotion fails, and Django falls back to the wrong INNER JOIN
> for Relation B/C in at least some cases involving 'select_related' and
> 'values'. In those cases the relation between A and B can either be an
> explicit foreign key (A -> B) or an implicit/reverse one such as introduced
> by one-to-one relations (e.g. in multi-table inheritance).
>
> I outlined those cases in #16715. I also provided two semi-elaborate tests
> for my observation ("wrong-join-test-r16910.patch" and
> "nested-foreign-key-test-r16914.patch").
>
>
> What do you think? Is this something that can be fixed easily? My fears are
> that this points to some deeper problem within the query generator, in which
> the generator fails to correctly promote the join type for the nested
> relation.
>
> Sebastian.
--
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.
Multi-DB support within transaction middleware
The current implementation of django.middleware.TransactionMiddleware does not create a transaction for each database, only the default one defined by DEFAULT_DB_ALIAS - https://code.djangoproject.com/browser/django/trunk/django/db/utils.py. Shouldn't the middleware manage a transaction for each database defined in the DATABASES setting? I discovered this while debugging some caching issues with the johnnycache library, which saves cached querysets when committing. In my case, all requests to databases other than default were not being cached. Happy to supply a patch and tests if this is sensible. -- *Dr. David Winterbottom* Head of Programming Tangent Labs 84-86 Great Portland Street London W1W 7NR England, UK -- 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.
Sane defaults for Startapp and Startproject
Hey guys! So I've just written a blog post about getting started with Django, http://gun.io/blog/python-for-the-web/, and many of the things here just make me think, 'why doesn't it just do that by default?' Here's some of what I propose. I'm not suggesting this be a canonical list of features by any means, I'm just suggesting that django have more convenient default settings. We should look at the most common conventions and best practices and shape the defaults towards them. Anyway, I propose that: django-admin.py startproject newproj should create ./static, ./uploads and ./newproj and ./newproj/ templates in ./newproj/settings.py.. import os TEMPLATE_DIRS = ( os.path.join(os.path.dirname(__file__), 'templates'), ) and at the end, the commonly used from local settings import * block. 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. 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). Who's with me? :) R -- 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
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: Sane defaults for Startapp and Startproject
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Rich, On 10/18/2011 04:21 PM, Rich Jones wrote: > So I've just written a blog post about getting started with Django, > http://gun.io/blog/python-for-the-web/, and many of the things here > just make me think, 'why doesn't it just do that by default?' > > Here's some of what I propose. I'm not suggesting this be a canonical > list of features by any means, I'm just suggesting that django have > more convenient default settings. We should look at the most common > conventions and best practices and shape the defaults towards them. Thanks for giving some thought to what would make Django easier for new users. > Anyway, I propose that: > > django-admin.py startproject newproj > > should create ./static, ./uploads and ./newproj and ./newproj/ > templates +0.5 to creating static/ and templates/ directories. I know people may use layouts where those live elsewhere, but I don't think I've ever seen a real production Django codebase that didn't have a directory for static assets and a main project-wide directory for templates, in the same repo with the code. - -1 to creating an uploads/ directory, I've seen (and written) many projects that never handle user uploads at all. > in ./newproj/settings.py.. > > import os > TEMPLATE_DIRS = ( > os.path.join(os.path.dirname(__file__), 'templates'), > ) If startproject creates a templates/ dir, +1 to having it in the default TEMPLATE_DIRS in a portable way like this. Same with static/ and STATICFILES_DIRS. > and at the end, the commonly used from local settings import * block. - -1; this is often done, but it's far from a consensus best practice. > 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. I'd be -1 on this as well for the same reason as Javier. > 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). - -1 on this; I frequently have a views.py that doesn't use one or more of these utilities (what if I prefer TemplateResponse instead of render_to_response?). Users should get used to the idea that you import what you actually need to use and don't have unused imports hanging around. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6eExEACgkQ8W4rlRKtE2cJAgCfdVEI4pysyolpayYs/oGvam20 WvIAnA34ivGF47ZczmCe/KAkHcqhhXAf =lpHn -END PGP SIGNATURE- -- 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
On Tue, Oct 18, 2011 at 5:21 PM, Rich Jones wrote:
> Hey guys!
>
> So I've just written a blog post about getting started with Django,
> http://gun.io/blog/python-for-the-web/, and many of the things here
> just make me think, 'why doesn't it just do that by default?'
>
> Here's some of what I propose. I'm not suggesting this be a canonical
> list of features by any means, I'm just suggesting that django have
> more convenient default settings. We should look at the most common
> conventions and best practices and shape the defaults towards them.
>
> Anyway, I propose that:
>
> django-admin.py startproject newproj
>
> should create ./static, ./uploads and ./newproj and ./newproj/
> templates
>
I personally +1 on the ./static and ./uploads. I like a starting point for
putting the static files and the uploaded files. If you don't use static
files or uploaded files, it'll never get used and deleting a folder is
pretty easy. For consistency, I'd rename ./uploads to ./media (to match the
MEDIA_ROOT notation used in settings.py). I'd also fill-in MEDIA_URL
('/media'), MEDIA_ROOT, and STATIC_ROOT to work out of the gate. Is there a
way to statically serve the MEDIA_ROOT folder to '/media/' without
collectstatic collecting it and/or findstatic finding it by default?
>
> in ./newproj/settings.py..
>
> import os
> TEMPLATE_DIRS = (
>os.path.join(os.path.dirname(__file__), 'templates'),
> )
>
>
+1 for something to accomplish this. I personally don't care how it's done.
> and at the end, the commonly used from local settings import * block.
>
-1 'from import *' should always be avoided. You never know what
can happen down the road that you may override later.
>
> 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 I can see why this seems like a good idea, but I agree that I don't want
anything touching my settings file. I also think people should learn how to
start a new app and about manage.py, startapp seems like the obvious answer
from a teaching perspective.
>
> 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).
>
>
-1 If the exception wasn't so blatently obvious and worded well in the
error, I might agree.
> Who's with me? :)
>
> R
>
> --
> 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.
>
>
I also want to add another change. Put TEMPLATE_CONTEXT_PROCESSORS in the
settings.py. I would just it rather be more explicit that you may be using
these things. If there's any other settings like this that 'slide' a default
value in w/o your knowledge, I'd like it to add to the settings.py by
default. Most problems I have helping people is a default value that's not
explicitly done in the settings.py, so people don't realize it's something
they can override (or may need to). My criteria would be anything that could
require modification (within reason) when adding or removing an app to make
the app work properly. (See TEMPLATE_CONTEXT_PROCESSORS as an example.)
--
Joe & Anne Tennies
tenn...@gmail.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: Sane defaults for Startapp and Startproject
I'd like the settings file to be more convenient too, but most of the
suggestion are too specific.
It's an excellent idea to automate more things, but it's a really bad
idea to pretend that we know
everybody's needs.
Personally here's what I'd like to see in the generated settings.py:
import os
PROJECT_PATH = os.path.dirname(os.path.abspath(__file__))
...
MEDIA_ROOT = os.path.join(PROJECT_PATH, 'media/')
...
TEMPLATE_DIRS = (
os.path.join(PROJECT_PATH, 'templates/'),
)
This would already be a big time saver.
Another things that would be nice is commonly used code like
TEMPLATE_CONTEXT_PROCESSORS,
some middlewares and apps being commented. This wouldn't hurt anybody
I think.
About adding stuff to views or other files generated by starapp or
startproject .. -1. I think the bare minimum is a win for everybody.
That said, it would be nice to let people write their own templates
for thoses files. Startapp and startproject could look for them
in a path like $USER/.django/templates/newapp/ or $USER/.django/
templates/newproject/ and/or let startapp/startproject accept
a --templates argument to make something like this possible:
python manage.py startapp myapp --templates=/some/path/templates/
newapp/
python manage.py startproject myproject --templates=/some/path/
templates/newproject/
my 2¢
On Oct 18, 9:20 pm, "Joe & Anne Tennies" wrote:
> On Tue, Oct 18, 2011 at 5:21 PM, Rich Jones wrote:
> > Hey guys!
>
> > So I've just written a blog post about getting started with Django,
> >http://gun.io/blog/python-for-the-web/, and many of the things here
> > just make me think, 'why doesn't it just do that by default?'
>
> > Here's some of what I propose. I'm not suggesting this be a canonical
> > list of features by any means, I'm just suggesting that django have
> > more convenient default settings. We should look at the most common
> > conventions and best practices and shape the defaults towards them.
>
> > Anyway, I propose that:
>
> > django-admin.py startproject newproj
>
> > should create ./static, ./uploads and ./newproj and ./newproj/
> > templates
>
> I personally +1 on the ./static and ./uploads. I like a starting point for
> putting the static files and the uploaded files. If you don't use static
> files or uploaded files, it'll never get used and deleting a folder is
> pretty easy. For consistency, I'd rename ./uploads to ./media (to match the
> MEDIA_ROOT notation used in settings.py). I'd also fill-in MEDIA_URL
> ('/media'), MEDIA_ROOT, and STATIC_ROOT to work out of the gate. Is there a
> way to statically serve the MEDIA_ROOT folder to '/media/' without
> collectstatic collecting it and/or findstatic finding it by default?
>
>
>
> > in ./newproj/settings.py..
>
> > import os
> > TEMPLATE_DIRS = (
> > os.path.join(os.path.dirname(__file__), 'templates'),
> > )
>
> +1 for something to accomplish this. I personally don't care how it's done.
>
> > and at the end, the commonly used from local settings import * block.
>
> -1 'from import *' should always be avoided. You never know what
> can happen down the road that you may override later.
>
>
>
> > 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 I can see why this seems like a good idea, but I agree that I don't want
> anything touching my settings file. I also think people should learn how to
> start a new app and about manage.py, startapp seems like the obvious answer
> from a teaching perspective.
>
>
>
> > 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).
>
> -1 If the exception wasn't so blatently obvious and worded well in the
> error, I might agree.
>
> > Who's with me? :)
>
> > R
>
> > --
> > 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.
>
> I also want to add another change. Put TEMPLATE_CONTEXT_PROCESSORS in the
> settings.py. I would just it rather be more explicit that you may be using
> these things. If there's any other settings like this that 'slide' a default
> value in w/o your knowledge, I'd like it to add to the settings.py by
> default. Most problems I have helping people is a default value that's not
> explicitly done in the settings.py, so people don't realize it's something
> they can override (or may need to). My criteria would be anything that could
> require modification (within reason) when adding or removing an app to make
> the app work properly. (See TEMPLATE_CONTEXT_PROCESSORS as an example.)
>
> --
> Joe & Anne Tenn
Re: Sane defaults for Startapp and Startproject
Hi Rich,
I'am not Django core but I think that most of your propositions are
unpythonic/unkiss, unclear and way too specific or magical.
I don't want to waste 10 more minutes after a startapp/startproject to
think about what directory I have to remove and which files I have to
repair because all those additions does not fit with my arch.
There is no rules about local_settings.py (sometimes my local
dispatchs live in settings.py and can deal with that :-) nor about
media, static, templates (in app, in project, both or outside ?).
I thing this is clearly not the way to follow and not the spirit of
Python/Django. Again, Keep It Simple.
Cheers,
Stanislas.
On Oct 19, 3:20 am, "Joe & Anne Tennies" wrote:
> On Tue, Oct 18, 2011 at 5:21 PM, Rich Jones wrote:
> > Hey guys!
>
> > So I've just written a blog post about getting started with Django,
> >http://gun.io/blog/python-for-the-web/, and many of the things here
> > just make me think, 'why doesn't it just do that by default?'
>
> > Here's some of what I propose. I'm not suggesting this be a canonical
> > list of features by any means, I'm just suggesting that django have
> > more convenient default settings. We should look at the most common
> > conventions and best practices and shape the defaults towards them.
>
> > Anyway, I propose that:
>
> > django-admin.py startproject newproj
>
> > should create ./static, ./uploads and ./newproj and ./newproj/
> > templates
>
> I personally +1 on the ./static and ./uploads. I like a starting point for
> putting the static files and the uploaded files. If you don't use static
> files or uploaded files, it'll never get used and deleting a folder is
> pretty easy. For consistency, I'd rename ./uploads to ./media (to match the
> MEDIA_ROOT notation used in settings.py). I'd also fill-in MEDIA_URL
> ('/media'), MEDIA_ROOT, and STATIC_ROOT to work out of the gate. Is there a
> way to statically serve the MEDIA_ROOT folder to '/media/' without
> collectstatic collecting it and/or findstatic finding it by default?
>
>
>
> > in ./newproj/settings.py..
>
> > import os
> > TEMPLATE_DIRS = (
> > os.path.join(os.path.dirname(__file__), 'templates'),
> > )
>
> +1 for something to accomplish this. I personally don't care how it's done.
>
> > and at the end, the commonly used from local settings import * block.
>
> -1 'from import *' should always be avoided. You never know what
> can happen down the road that you may override later.
>
>
>
> > 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 I can see why this seems like a good idea, but I agree that I don't want
> anything touching my settings file. I also think people should learn how to
> start a new app and about manage.py, startapp seems like the obvious answer
> from a teaching perspective.
>
>
>
> > 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).
>
> -1 If the exception wasn't so blatently obvious and worded well in the
> error, I might agree.
>
> > Who's with me? :)
>
> > R
>
> > --
> > 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.
>
> I also want to add another change. Put TEMPLATE_CONTEXT_PROCESSORS in the
> settings.py. I would just it rather be more explicit that you may be using
> these things. If there's any other settings like this that 'slide' a default
> value in w/o your knowledge, I'd like it to add to the settings.py by
> default. Most problems I have helping people is a default value that's not
> explicitly done in the settings.py, so people don't realize it's something
> they can override (or may need to). My criteria would be anything that could
> require modification (within reason) when adding or removing an app to make
> the app work properly. (See TEMPLATE_CONTEXT_PROCESSORS as an example.)
>
> --
> Joe & Anne Tennies
> tenn...@gmail.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.
