Re: Multiple database support: Request for feedback and testing
> 1) Ignore the problem. Admin works on the default database, but > nowhere else. This is certainly less than ideal, but it would be > sufficient for master/slave setups. > > 2) Use a separate admin deployment for each database. We add a 'using' > argument to admin.Site(), and append .using() the queries that the > admin site issues. > > 3) Modify the admin list views so that they take a ?using=db GET > argument; also add a pulldown to make it easy to switch to a different > database. > > (2) should be a fairly minor change; (3) would be a little more > effort, but shouldn't be impossible. There is also the need for some > mechanics to check whether a table is actually present on a database - > just because auth is in INSTALLED_APPS doesn't mean it's been > synchronized to a particular database. > > I'm open to any other suggestions - and for any offers to help out :-) Just thinking of one more option for this -- what about specifying the DB on the ModelAdmin level rather than the admin.Site level? -- 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.
extra_context in all admin views?
I've been subclassing AdminSite for a recent project, and am curious whether there's a particular reason why the login, logout, and change_password views shouldn't take extra_context the way most of the other views do? thanks, -Nan -- 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: drop Python 2.5 support in Django 1.5
FWIW, the previous version of Mac OS X (10.6) shipped with 2.6.1. On Dec 23, 5:49 am, Vinay Sajip wrote: > On Dec 10, 4:56 pm, Adrian Holovaty wrote: > > > I think both of these proposals are great -- start merging the Python > > 3 work right after we release 1.4, anddropsupport for Python2.5in > > trunk after 1.4 is released. > > Before we do this, another decision is required - which release of 2.6 > is the minimum Django should support? There was a change which > occurred with 2.6.5 (IIRC) to allow Unicode in kwargs keys (earlier > versions would raise an exception). > > If we use "from __future__ import unicode_literals" to avoid using u() > and b(), then a lot of Django code will be affected. Supporting 2.6->2.6.4 > will require cleaning kwargs, and to avoid this one would need > > to state that Django will only support 2.6.5 onwards. Of course, that > might affect quite a lot of users with 2.6 system Pythons which are < > 2.6.5 (e.g. on Ubuntu Jaunty the system Python is 2.6.2). > > Regards, > > Vinay Sajip -- 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: reboot
> However not all databases have this same behavior when trying to insert a > string that is longer than > the field allows. This means that for a certain subset of Django developers > if they didn't read the > releases note, or just missed that section of it that Django would not > validate the length of the > field to be 30, but would instead validate it to be much longer, Django would > pass it to the database > who for those users it would silently truncate the data. Would something like the following alleviate that problem? class User(models.Model): if settings.USE_LONG_USER_FIELDS: username = models.CharField(max_length=255, unique=True, ...) else: username = models.CharField(max_length=30, unique=True, ...) ... So you have three cases: 1) New app; settings.py generated with USE_LONG_USER_FIELDS=True; table generated with full-length fields on syncdb; no problem. 2) Existing app; user doesn't read the docs, doesn't change settings; field still gets set to max_length=30, no data loss 3) Existing app; user reads the docs, changes the settings, and updates his database. This way you'd only get data loss if someone manages to read the docs closely enough to update the settings but not the DB, which IMO is something that gets addressed by calling it out very clearly in the documentation anywhere the setting is mentioned. Just an idea... -Nan -- 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: TemplateResponse and loader should handle request
It would be really nice to be *able* to create a template loader that can use the request object. If, for instance, you have a site that needs to be able to change the template used based on user preferences or based on the current Site object, it's a lot cleaner to be able to do that once in a custom template loader than to have to write (or inherit) that into every single view -- especially once you start integrating third-party apps with their own not-necessarily-class- based views. On Nov 10, 6:27 am, Tom Evans wrote: > On Thu, Nov 10, 2011 at 10:20 AM, Florian Apolloner > > > > > > > > > > wrote: > > Hi, > > > On Thursday, November 10, 2011 10:43:01 AM UTC+1, Tom Evans wrote: > > >> Please no - an optional argument is all well and good, until people > > >> I don't get why it is difficult to extract what you want from the > > >> request, place it in a context and render it. > > > I think you missunderstood me, I didn't ment to add a optional keyword > > argument like request, but pass **kwargs down the chain -- The current > > template loaders would just ignore it completly but users might override it > > to supply extra data to their template loader. Either way it was just a > > suggestion and I am not really sold on it either… > > > Cheers, > > Florian > > I tend to lurch from one extreme to another - I've calmed down a little now! > > I worry about coupling things to the request, having used frameworks > where that has happened over time. It always leads to problems down > the line, as in my experience, a lot of what happens on a web site > happens outside of the request/response cycle. > > It's already pretty hard to generate the same content outside of a > request/response if your template expects things from > TEMPLATE_CONTEXT_PROCESSORS. > > Cheers > > Tom -- 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.
