Re: AnonymousUser has_perm/has_module_perms function check authentication backends
> > The point is that as the developer of a reusable application you don't > know what *anyone* can do, and you should be able to abstract that by > querying the backend. > +1 As a reusable app developer, I'd prefer to develop my app and ship it with a set of permissions which control access to various aspects of functionality. It's then up to the end integrator to decide whether an anonymous user has or does not have a given permission. Allowing anonymous users to have permissions lets you put security policy in the hands of the end integrator. This has worked extremely well in the Zope/Plone world; changing a public website to one that requires authentication is simply a case of removing the standard 'View' permission from anonymous users. Cheers, Dan -- Dan Fairs | http://www.fezconsulting.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-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.
Possible regression with serializers in 1.4
Hi, I'm working on porting a large codebase to 1.4 (using the rc), and have run into what appears to be a regression in the serializers. I wanted to run it past some eyes here before I raise a ticket. The Python serializer's handle_fk_field() method now no longer handles the case where a related object is None and natural keys are in use. The problem appears to have been introduced in this changeset: https://code.djangoproject.com/changeset/17439 The code now no longer checks to see if the `related` object is not None before attempting to call natural_key() on it. Should I raise a ticket for this one? Cheers, Dan -- Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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.
Migrating to 1.4
Hi, Since most people only ever report bugs, I wanted to report success in the initial migration of a relatively large project (~35k lines of Python application code, excluding comments and migrations, with ~43k lines of test code over ~2.5k tests) to Django 1.4 rc1. The production environment is running Django 1.3.1. Both are using Python 2.7.2 and MySQL. Relatively few changes were necessary. There were a couple of bumps on the way (bugs #17879 and #17891) which were fixed quickly. I also had to spend some time updating some of our code which customises bits of Django that don't look like they were meant to be customised. We have custom logic for computing template lookup paths that depends on the request (skinning, basically), which doesn't 'fit' into a custom template loader. 'Normal' views are handled by way of an overridden get_template_names() in a base view - all our views are class-based, but: - We have a custom template tag that derives from ExtendsNode, and overrides get_parent - We have a custom Library implementation that overrides inclusion_tag(), which knows about our template lookup logic; it broke because the signature for generic_tag_compiler changed. Both of these were fixed by using the new implementations from Django itself, and re-applying our small changes. Should I raise backwards-incompatibility tickets for these? They're pretty obscure, and I can't imagine many people are doing them. I raised #17891 because the code involved a clear extension point. At this point, everything else seems to have 'just worked' - including some moderately scary model generation code - and I was finally able to remove our `backports` app containing signed cookies and cookie-based sessions, and our build-time patch for select_for_update(). Next up is checking that there aren't any significant performance regressions. Thanks, everyone! Cheers, Dan -- Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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: Migrating to 1.4
Hi, >> Both of these were fixed by using the new implementations from Django >> itself, and re-applying our small changes. >> >> Should I raise backwards-incompatibility tickets for these? They're pretty >> obscure, and I can't imagine many people are doing them. I raised #17891 >> because the code involved a clear extension point. > > Thanks for sharing this story, Dan! It's great to hear. Let us know > about the performance differences (if any), too. Well, we're finally getting into the performance side of things now! The first big regression for us was that our test suite took 20% longer to run. I traced this down to the new default password hasher. This is clearly by design - and we'll just use the PASSWORD_HASHERS setting to use a faster (and much less secure) hasher for test runs. Fortunately our app uses an external authentication service for most of its users, so this won't affect us in production - but for those running sites with high signup rates, this could be a surprise. Is that worth a mention in the release notes? Cheers, Dan -- Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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: Model inheritance extended.
> On 24 syys, 16:55, Jonathan Slenders > wrote: >> This may be interesting to some of you. I created a small library for >> inheritance of *a set of* models. >> It's best to go quickly through the Readme on the site below. >> >> We felt a need for this, but I'm wondering whether some kind of inheritance >> like this has been discussed before. And whether, if useful, this would >> make a candidate for django.db. >> >> https://github.com/citylive/django-model-blueprint > > Looks interesting! It is nice to see how little code you needed to > implement this. Inheriting a system of models should be useful in some > special circumstances. I know I have missed that feature at least > once... > fwiw, I've implemented something like this in another project, as well. It did more stuff (model partitioning for large data volumes, handling the case of deriving from generated base classes, shared models between 'blueprints'), but the core of yours looks pretty neat. Cheers, Dan -- Dan Fairs | dan.fa...@gmail.com | @danfairs | www.fezconsulting.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: Changing settings per test
> Let me start with an example test: > > def test_with_awesome_setting(self): >_orig = getattr(settings, 'AWESOME', None) >settings.AWESOME = True > ># do my test >... > >settings.AWESOME = _orig > Pedant: there's a small bug above which has bitten me before doing a similar thing - settings.AWESOME ends up set to None after the test has run if it didn't exist before. > Anyways, I'd love to hear how others have dealt with this and any > other possible solutions. I've used Michael Foord's Mock library to patch a setting for the duration of a test case. Chris Withers' testfixtures library also has some sugar to provide a context manager approach, though I haven't used that in a little while. Cheers, Dan -- Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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-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.
Unexpected behaviour when providing bad input to CheckboxInput
Hi,
I've come across some interesting behaviour if you intentionally supply bad
data to a model formset whose forms use CheckboxInputs. Basically, it's
possible to have custom validation code on the form class which ensures the
boolean field's input is False, have this validation pass, but then the
instance silently fails to save to the database when you call formset.save()
when an instance's existing value is True.
The way to do this is to provide a '0' as input on the form submit, rather than
omitting the field entirely, as a proper checkbox widget would do.
This is more easily explained with code:
class M(models.Model):
flag = models.BooleanField()
class DefaultModelForm(forms.ModelForm):
# This form will get an auto-generated BooleanField, which uses
# the CheckboxInput widget.
class Meta:
model = M
def clean(self):
# Now, because BooleanField.to_python knows about '0',
# cleaned_data actually contains False. '0' and '1' can
# be posted by RadioSelect widgets.
cleaned_data = super(DefaultModelForm, self).clean()
if cleaned_data.get('flag', None) != False:
raise ValidationError, u'Flag must be false!'
return cleaned_data
class SimpleTest(TestCase):
def setUp(self):
# Let's set up a signal handler so we can tell whether the model was
saved.
self.save_count = collections.defaultdict(int)
def saved(sender, **kwargs):
self.save_count['count'] += 1
signals.post_save.connect(saved, sender=M, dispatch_uid='M')
self.m = M.objects.create(flag=True)
# Prove our plumbing works
self.assertEqual(1, self.save_count['count'])
def test_checkbox(self):
formset_class = forms.models.modelformset_factory(
M,
max_num=1,
form=DefaultModelForm
)
# Note that 'form-0-flag' being 0 is what a radio button
# would normally provide.
formset = formset_class({
'form-INITIAL_FORMS': '1',
'form-TOTAL_FORMS': '1',
'form-0-id': str(self.m.pk),
'form-0-flag': '0',
}, queryset=M.objects.all())
# Uh-oh - this now validates as True, because the BooleanField
successfully
# parsed '0' as False, but the CheckboxWidget doesn't know what to do
with
# '0'.
formset.is_valid()
# Since all the data looks OK, we go ahead and try to save. To compound
# the problem, the CheckboxWidget sees that the initial value from the
# model was True, and interprets '0' as bool('0') == True, so doesn't
# think that the data has changed. The model therefore never actually
# gets saved...
formset.save()
# If it saved properly, our save count should have gone up by one.
Sadly,
# it didn't, so this test fails.
self.assertEqual(2, self.save_count['count'])
# So - despite is_valid() assuring us that all our data was OK, saving
the
# model silently failed.
I've tried this with Django 1.2.3 and trunk r14735.
I'm not quite sure what the bug is here, if there is one; but it seem wrong
that you can write validation code that explicitly checks cleaned_data for a
boolean to be False, have that validation pass, and then for the underlying
model to not be saved when the formset save() is called.
(For the curious - we discovered this while writing tests for a Piston API that
uses formsets to validate data, and accidentally passed a '0' instead of
omitting the field in the test.)
Should I raise a bug for this one?
Cheers,
Dan
--
Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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-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.
DatabaseError swallowed?
lf.cursor.execute(sql, params)
File
"/Users/dan/virtual/ism/django/parts/django/django/db/backends/mysql/base.py",
line 86, in execute
return self.cursor.execute(query, args)
File
"/Users/dan/.buildout/eggs/MySQL_python-1.2.3-py2.6-macosx-10.6-universal.egg/MySQLdb/cursors.py",
line 174, in execute
self.errorhandler(self, exc, value)
File
"/Users/dan/.buildout/eggs/MySQL_python-1.2.3-py2.6-macosx-10.6-universal.egg/MySQLdb/connections.py",
line 36, in defaulterrorhandler
raise errorclass, errorvalue
DatabaseError: (1146, "Table 'ismdj.piston_token' doesn't exist")
Is this expected behaviour, where an exception is only raised when models are
iterated over?
For reference, here's a rough, slightly abbreviated version of the test code I
have so far for the patch I'm working on. The interesting code is marked with a
# XXX, but the context may be useful (I'm trying to look for a DatabaseError
that will be returned by the database due to being unable to get a lock):
from models import Person
class SelectForUpdateTests(TransactionTestCase):
def setUp(self):
connection._rollback()
connection._enter_transaction_management(True)
self.new_connections = ConnectionHandler(settings.DATABASES)
self.person = Person.objects.create(name='Reinhardt')
def start_blocking_transaction(self):
self.new_connection = self.new_connections[DEFAULT_DB_ALIAS]
self.new_connection._enter_transaction_management(True)
self.cursor = self.new_connection.cursor()
sql = 'SELECT * FROM %(db_table)s %(for_update)s;' % {
'db_table': Person._meta.db_table,
'for_update': self.new_connection.ops.for_update_sql(),
}
self.cursor.execute(sql, ())
result = self.cursor.fetchone()
def end_blocking_transaction(self):
self.new_connection._rollback()
self.new_connection.close()
self.new_connection._leave_transaction_management(True)
def get_exception(self):
from django.db.models.sql.query import LockNotAvailable
return LockNotAvailable
def run_select_for_update(self, status, nowait=False):
status.append('started')
try:
connection._rollback()
people = Person.objects.all().select_for_update(nowait=nowait)
# for person in people:
# person.name = 'Fred'
# person.save()
# XXX
people = list(people)
connection._commit()
status.append('finished')
except Exception, e:
status.append(e)
@skipUnlessDBFeature('has_select_for_update_nowait')
def test_nowait_raises_error_on_block(self):
"""
If nowait is specified, we expect an error to be raised rather
than blocking.
"""
self.start_blocking_transaction()
status = []
thread = threading.Thread(
target=self.run_select_for_update,
args=(status,),
kwargs={'nowait': True},
)
thread.start()
# We should find the thread threw an exception
time.sleep(1)
self.end_blocking_transaction()
thread.join()
self.assertTrue(isinstance(status[-1], self.get_exception()))
The interesting part is the code marked with # XXX. As it stands, that line
produces a simple empty list. Commenting that and uncommenting the 'for person
in people' stanza causes a DatabaseError to be (correctly) raised.
This is a problem for this patch, as it's difficult to tell the difference
between no records returned, and the database being unable to get a row lock in
the case for FOR UPDATE NOWAIT.
Cheers,
Dan
--
Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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-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: DatabaseError swallowed?
Hi, > On 12/02/2010 03:43 PM, Dan Fairs wrote: >> My gut feeling is that this boils down to this vastly simplified >> demonstration of how list() works: >> >>>>> class Foo(object): >> ... def __len__(self): >> ... print 'len called' >> ... raise ValueError >> ... def __iter__(self): >> ... return iter([1,2,3]) >> ... >>>>> a = Foo() >>>>> list(a) >> len called >> [1, 2, 3] >> >> Here, you can see that when converting to a list, Python calls __len__, and >> if that raises an exception, discards it and goes on to call __iter__. >> >> So - my hypothesis (unproved, as I could benefit from someone with deeper >> ORM knowledge) is that the call to list() in my original test case calls >> QuerySet.__len__(), which ends up raising a DatabaseError (caused by an >> underlying database lock, the behaviour I'm actually testing for). Python's >> subsequent call to QuerySet.__iter__() succeeds, but ends up returning an >> empty iterator due to some pre-existing state *handwaving here*. >> >> It's the handwaving bit I'm not sure about :). Does that hypothesis sound >> plausible? It seems to be borne out by the snippet below, where I've removed >> the underlying table: > > I ran into this issue, too. My workaround was to place a > >if hasattr(self._iter, '__len__'): >len(self._iter) > > and the same for self.generator in QuerySet.__len__. > > Btw, there's a bug report for this from 2009: > http://bugs.python.org/issue1242657 > Right - I remember that regression actually. > I was wondering whether the bug still exists in Python 2.x because I take it > only AttributeError and TypeError should be ignored while calling __len__ in > list() -- if that's the case, the bug is definitely still present. True - I'll give it a try in 2.7 when I have a moment to grab and build it. That doesn't help us that much though, as 2.6 (which I'm running on, 2.6.1 to be precise) is a supported version. > > Anyway, I propose to call len() on those iterators, if possible, before > calling list() because otherwise all bugs in backends will be swallowed. That makes sense. I'd considered proposing storing any exception raised in __len__ on an instance variable to be re-raised later; but your solution is better, as you'd get better tracebacks. Should I raise a bug for this behaviour? Working up a test and patch should be straightforward for this one, if we agree it's a bug that needs fixing (even if it's a workaround for the underlying Python issue). Cheers, Dan -- Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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-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: DatabaseError swallowed?
> I tested it on my machine and it raises ValueError on: > > * Python 2.4.6 > * Python 2.5.5 > * Python 2.6.6 > * Python 2.7.0+ > * Python 3.1.2 > > If you have version 2.6.1, you should upgrade. I don't think Django > should support a Python bug that was fixed almost 2 years ago. > Cool - the Python I'm using is a Mac OS X Snow Leopard system Python. I'll rebuild my dev environment with a newer Python. Cheers, Dan -- Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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-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.
RFC #2705 (Support for SELECT FOR UPDATE)
Hi, I've been trying to clean up the patch on #2705, which adds support for SELECT..FOR UPDATE. It now has docs and tests, which pass on SQLite, PostgreSQL and MySQL. I've mainly worked on the tests and docs, not the core content of the patch, but I'd welcome any comments on the implementation as well - I'd like to see this get in (be it in a 1.3 or 1.4 timeframe) so if any changes are needed for that, then that's fine. I'd also appreciate it if someone with access to Oracle could give the patch a try. http://code.djangoproject.com/ticket/2705 (Incidentally, brunobraga is the owner of this ticket currently - should I claim it?) Malcolm's main gripe was the API. If anyone has any better ideas - I'm all ears! Thanks, Dan -- Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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-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: RFC #2705 (Support for SELECT FOR UPDATE)
> > On Tue, Dec 21, 2010 at 10:31 AM, Dan Fairs wrote: >> I've mainly worked on the tests and docs, not the core content of the patch, >> but I'd welcome any comments on the implementation as well - I'd like to see >> this get in (be it in a 1.3 or 1.4 timeframe) so if any changes are needed >> for that, then that's fine. I'd also appreciate it if someone with access to >> Oracle could give the patch a try. > > I'm on vacation now and don't have easy access to an Oracle setup, but > I'll be happy to try it next week if nobody else has done it first. > Thanks for the offer, Ian. Ramiro took the patch for a spin, and it worked OK (after some tweaks for Python < 2.6, and a missed empty __init__.py - thanks!). For the benefit of the archives, Ramiro's comment highlighted a wiki page on getting an Oracle setup going: http://code.djangoproject.com/wiki/OracleTestSetup I'll re-apply Ramiro's patch locally and make sure everything still checks out for me, and report back. Cheers, Dan -- Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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-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: Add current_app to request and pass it to template loaders.
Some tags you could potentially add 'hidden' values like __theme__ in
the context using RequestContext and then have the tags pass those on
to get_template(). Assuming tags played nicely and always passed along
those values to their nodelists contexts.
Other tags like {% include "app/sometemplate.html"%} get the template
at compile time of the parent template. The compiled template might
be cached, or otherwise re-used - so that approach isn't reliable.
I hope there is a solution I overlooked.
I've implemented something similar to this without threadlocals, using
the new class-based views infrastructure. You can override
TemplateView.get_template_names to return an iterable of template names
(by default it returns [self.template_name], actually defined in
TemplateResponseMixin).
You can then vary what you return based on the request, which is
available as an attribute of the base view class.
Cheers,
Dan
--
Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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: Django urls in JavaScript
That's also already done, check
https://github.com/django-extensions/django-extensions/blob/master/django_extensions/management/commands/show_urls.py,
it can be easily converted to JSON (I have a branch that does it, but
it's not up-to-date).
I also have the urls module in JavaScript already, but as part of a
larger library (https://github.com/mlouro/olivejs/blob/master/olive/
urls/urls.js), both have been used in projects.
An example:
/* below is the output from "manage.py show_urls" in JSON format */
olive.urls.load({
'dashboard': '/dashboard/',
'time_edit': '/projects//time/save//',
'task_edit': '/projects//task/save//'
});
olive.urls.get('task_edit', {
'project_id': 2,
'task_id': 1
})
This all sounds pretty cool - I'd love to be able to reverse URLs in
JavaScript. Keep in mind, though, that URLConfs can change on a
per-request basis, by setting request.urlconf. Any JSON data structure
representing the URLConf would need to be generated after this has been
set (ie. some time after request middleware has been processed, look at
django.core.handlers.base:94-98). Having a template tag would probably
be fine, as the URLConf is set by render time, but don't expect to be
able to do a one-off analysis of the URLConf at application startup.
Cheers,
Dan
--
Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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: Template Compilation
- preprocess inheritance. (one important incompatibility: {% extend
"..." %} should only get a string as parameter, not a variable! But
honestly, I really don't know why someone would do that.
For the record - we do!
We don't have a core site base template. Each client on our system gets
their own, as IA/branding etc. varies considerably (and indeed includes
chunks of markup that the client supplies directly).
However, the 'content' views are all actually the same between clients.
We therefore simply vary the base template depending on the domain of
the incoming request; the base template to use while rendering a given
template is put in the template's context. We have a couple of
'well-known blocks' (eg. {% content %}) which child templates can provide.
This lets us write a single set of views with a single set of templates
that work across all clients. We don't have to write 'child' templates
for every view for every client which pull in the right base template
for that client. We simply implement a base template for that client,
with that client's custom markup, and we're good to go.
There are other possible implementations, of course; but it turned out
that being able to determine the base template dynamically solved our
problem pretty elegantly.
Put a feature in, and someone, somewhere will be using it :)
Cheers,
Dan
--
Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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: RFC #2705 (Support for SELECT FOR UPDATE)
Hi, Now 1.3's out the door, I'd like this to be looked at again, if possible. http://code.djangoproject.com/ticket/2705 I'll re-apply Ramiro's patch locally and make sure everything still checks out for me, and report back. The latest version of the patch still applied cleanly for me and passed tests when I tried it again late last week (r15043). I hope Jacob's comments about the tests has now been addressed - a mistake in transaction setup was masking an error. The tests should now be sane, and pass for me on MySQL, PostgreSQL, SQLite and Oracle. I'd welcome review and feedback on improving the patch; I'd welcome seeing it merged even more. :) Cheers, Dan -- Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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: RFC #2705 (Support for SELECT FOR UPDATE)
Hi, Sorry to bump this one again. Now 1.3's out the door, I'd like this to be looked at again, if possible. http://code.djangoproject.com/ticket/2705 I'll re-apply Ramiro's patch locally and make sure everything still checks out for me, and report back. The latest version of the patch still applied cleanly for me and passed tests when I tried it again late last week (r15043). I've cleaned up the docs as per Jacob and Carl's points in their last review (thanks for those!). As mentioned in the ticket, I've also run the full suite against PostgreSQL, MySQL, SQLite and Oracle; there are no more breakages after the patch was applied than before it was applied. However, it's worth mentioning that the Oracle tests seemed to be mostly broken in the first place, with dozens of errors. Aside from the docs issues that I've fixed, Jacob said he thought this was RFC - it'd be great to see that happen. As ever, let me know on the ticket if there's anything else that needs to be done. Thanks, Dan -- Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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: RFC #2705 (Support for SELECT FOR UPDATE)
Thanks for following up on those. I reviewed the Oracle tests shortly before the 1.3 release and fixed all the real failures in the backend. The remaining failures as of then were due to the backend not interacting well with the test suite as documented in ticket #15573, plus a DB cache issue in #15580. Thanks for that, Ian. It sounds like those Oracle failures aren't related to this patch, then. Is there anything else that needs to be done before 2705 can be merged? Cheers, Dan -- Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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: Speed up models.Model.__init__: deprecate pre_init and post_init signals?
> Deprecate pre_init and post_init signals. I wonder if these are > actually used in third-party code. These signals are not the easiest > to use, as they get the field values in *args, or in **kwargs, or part > in *args, part in **kwargs. Django core uses them in generic foreign > keys: > To leap in here - we use post_init in our application, so there's at least *one* consumer out there! We use them to populate attributes on a model which depend on other system state, including data in that model itself. In our case, we actually only care about the instance passed in kwargs. There may be another way of doing what we're doing without post_init, but I'd need to look into it. Cheers Dan -- Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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: TemplateResponse and loader should handle request
> in my opinion, the loader object should handle the request, so that > can be sublassed to pass different template folder based on request > params. > > i need this feature for my app, is it possible to have different > template folder based on request params with the current django > release? If you're using class-based views, override get_templates to provide the right templates for the request. It's not quite a tidy to handle inclusion tags though - you need to subclass django.template.base.Library, and override inclusion_tag, grabbing the request out of the context (use the 'request' context processor) - then use whatever mechanism you used before to pick a template based on the request. Cheers, Dan -- Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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: I want a pony: Django Cheeseshop
>> >> Does anybody else actually do this? Last I checked, Pylons, >> TurboGears >> and Zope apps didn't install or need to be installed into >> framework-specific locations. Django applications are just Python >> modules, and that's a *strength* from where I sit. > > 100% with James here. I had a discussion about namespace packages [1] > with Mark Ramm at PyCon, and hist short answer was "don't do it, it > isn't worth it". Seeing as he's the maintainer of TurboGears and > probably knows setuptools about as well as anyone, I'd tend to trust > him on that one. I understand the appeal, but the consequences aren't > worth it. > > J +1 on just packaging stuff as eggs, and being able to easy_install them. Works great with my buildout infrastructure for managing Django builds too. I wouldn't worry about putting stuff that's not useful outside a Django context up; that's exactly what the categories system is for. There's plenty of Zope stuff there, for example, and I personally haven't seen any complaints. Maybe I just missed them. On the namespace package front, I'd be wary; I started trying to use them, but a client of mine on Windows has experienced problems using them in Django (in places where some __import__ magic is done). I'll raise a ticket when I get down to a minimal example. Cheers, Dan -- Dan Fairs <[EMAIL PROTECTED]> | http://www.stereoplex.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: user-friendly API for multi-database support
> 2. Have a setting which lets you say "for model auth.User, use the > get_connection method defined over here". This is made inelegant by > the fact that settings shouldn't really contain references to actual > function definitions, which means we would probably need to us a > 'dotted.path.to.a.function', which is crufty. The admin takes a registry-based approach to associate ModelAdmin classes with Models. Could a similar approach work here? myapp/connections.py: from django.contrib.multidb import connection from myapp.models import MyModel class MyModelConnection(connection.ModelConnection): def __call__(self): ... return a database connection ... connection.register(MyModel, MyModelConnection) I guess there's no reason even for MyModelConnection to be a class; a callable would do. Just a thought. Cheers, Dan -- Dan Fairs <[EMAIL PROTECTED]> | http://www.stereoplex.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Problem with object values in Django 1.0
>
> This is what my model looks like at the moment
>
> class Poll(models.Model):
>question = models.CharField(max_length=200)
>pub_date = models.DateTimeField('date published')
>
> def __unicode__(self):
>return self.question
Your indentation is wrong. The 'def __unicode__' line needs to be
intended to the same level as question and pub_date, else it won't be
considered part of the Poll class.
Cheers,
Dan
--
Dan Fairs <[EMAIL PROTECTED]> | http://www.fezconsulting.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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Problem with object values in Django 1.0
Sorry - should also have mentioned that this should be on django-users.
On 31 Oct 2008, at 14:28, Opel wrote:
>
> I have been following along to the Django Tutorial after downloading
> and installing V1.0. Everything is working fine apart from when I try
> to use the python shell to return the objects names. I tried to skip
> the step but when I tried to create the select menu of Polls for the
> Choices all that was returned was "Poll Object" instead of the name.
>
> This is what my model looks like at the moment
>
> class Poll(models.Model):
>question = models.CharField(max_length=200)
>pub_date = models.DateTimeField('date published')
>
> def __unicode__(self):
>return self.question
>
>
> class Choice(models.Model):
>poll = models.ForeignKey(Poll)
>choice = models.CharField(max_length=200)
>votes = models.IntegerField()
>
> def __unicode__(self):
>return self.choice
>
> When I do
>>>> from mysite.polls.models import Poll, Choice
>>>> Poll.object.all()
>
> I get "poll.object" instead of a name. Could anyone point out where I
> am going wrong please?
>
> Thanks
>
> >
--
Dan Fairs <[EMAIL PROTECTED]> | http://www.fezconsulting.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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
