dbsync for mysql lacks effective foreign key constraints, ticket #2720
Hi, that's a real bugger ... whenever a ForeignKey refers to a model that has already been defined (i.e. it is not a forward reference), the table created from it will *not* have an effective foreign key constraint. The sad details are in the ticket ... I've tested the patch with mysql4.1, postgresql 8.1, and sqlite3. Can anybody test it with ado_mssql, please? I'm now dreaming of a test service that would automatically run the testsuite for a given patch (or multiple patches) with all supported database backends ... Michael --~--~-~--~~~---~--~~ 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: Critical ticket: can cause data loss
On 30/01/07, James Bennett <[EMAIL PROTECTED]> wrote: > > On 1/29/07, Ned Batchelder <[EMAIL PROTECTED]> wrote: > > I don't know that you need to make a release for this fix, but I think you > > should alert people to it. There is a mailing list for announcing releases > > and security issues, right? You should send a message to that list > > announcing the patch. > > I will once I've backported it. The question in my mind is just > whether we need 0.95.2 from this. > I'm +1 on this too. I believe backports and point releases should be made for the following types of bugs: - security - availability e.g. crashing bugs - data integrity e.g. anything that causes data corruption, deletion etc. They cover off what most software vendors consider critical issues. Maybe the triage team could add keywords to that effect to tickets? regards matthew --~--~-~--~~~---~--~~ 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: Comments requested on two serializer related fixes
On 1/30/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Article.authors = [Author(id) for id in [4,7]] > > I.e. Author(id) creates some strange incomplete object that can be > nonetheless used for m2m relations since only an id is needed. Would > this suffice? I hadn't considered that approach. I'm not a big fan of the half-complete object instance, though. It strikes me as a little messy, and if it were accidentally saved, you would get some interesting fireworks. However, it would work, and you can't argue with results. That said, Adrian has stepped in and committed #3389 for me, which renders this part of the conversation moot. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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: Comments requested on two serializer related fixes
On 1/29/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On 1/29/07 7:22 AM, Russell Keith-Magee wrote: > > I've just created two new tickets - #3389 and #3390. > > I'm +1 on #3390 (the ``DEFERRABLE INITIALLY DEFERRED`` bit); that makes a few > other bulk-insert type tasks besides deserialization much easier. Agreed. It's a biggish change though, so i'd like to get some more community opinion or a blessing from Adrian before I push this in. > do the same thing seems a little weird. I guess I'd say I'm +0 unless anyone > can think of a better way... Yes, they do the same thing, but only if you actually have access to the (previously saved) instances john and fred. If you only have the primary key value as you do in deserialization, its: article.author_set = Author.objects.filter(pk_in=[4,7]) which hits the database, which is problematic if the objects haven't been saved yet. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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: New branch: newforms-admin
On 1/16/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > I'd like to take the clean route and move the admin definitions into a > separate file, or at least still in the models.py but not within the > models themselves. Of course, that's not as convenient as defining the > admin stuff directly within the model, but another solution would > require more typing and possible repetition. I think I've figured out how we might decouple things while still keeping convenience intact. If nothing else, maybe this will spark some more ideas. First, let's introduce a new class, let's call it ViewRegistry. It can return urlpatterns by calling its get_urlpatterns method. The include function in django.conf.urls.defaults should be updated to accept an instance of this class, or a string path to an instance. ViewRegistry will also have a register method that takes a model class and a subclass of ModelAdmin. That much gives us a way to setup multiple admin systems (loosely speaking). It's coupling views and urls, but IMHO this is an instance of controlled coupling for convenience a la django.shortcuts Now for convenience. Somewhere in django.contrib.admin we should instantiate ViewRegistry as a module global. When a model class is being setup and it has an inner Admin class, automatically register it with this ViewRegistry instance. The inner Admin class would not be an explicit sublass of ModelAdmin, nor would we do any magic to make it so. Instead, we could treat it simply as configuration data and pass it into ModelAdmin's constructor as a second arugment. (The model class itself still being the first. I really like how that works right now.) I haven't figured out how to specify a custom ModelAdmin subclass inside the model defentition yet. Adding a new admin_view attribute to the inner Admin class immediately pops out at me, but if we're passing that Admin class into the ModelAdmin's constructor, well... there's a weird circularity there that hurts my head. Joseph For bonus points maybe we could add the other admin views, password_change, logout, and maybe even the login_required decorator as methods of ViewRegistry. --~--~-~--~~~---~--~~ 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: reverse caching of foreign keys #3369
It's a lot more efficient, for one. select_related() generates more code to query the database. It also goes as "far as possible", so if the blog has a lot more relationships to it or if the entries have a lot more relationships to them, then select_related would be pretty inefficient especially since it already knows the exact object for the blog. If you already have the information, then why query the database for it? Why not just cache it right away? Other reasons it's different... b = Blog.objects.get(id=1) for entry in b.entry_set.all(): entry.blog is b # True Ok, so that might not be a big deal in most cases, but imagine the blog object does some calculations that each blog entry might want to know about. (This is the case in my application, but with different models). If each blog is a fresh object from the database, then this information would have to be recalculated for each object accessing the original blog. But if the blog caches it and it's the same blog every time, then everything's a lot faster. Just a code example that might help explain what I was trying to say: b = Blog.objects.get(id=1) for entry in b.entry_set.all(): calculated = entry.blog.do_some_heavy_calculation() entry.handle(calculated) The reason for not just using the original b object? Well if you're passing your list of entries to a view (and don't want to pass the blog object as well because - well, why should you have to?), then this situation is very real. Another reason... select_related() isn't needed here and shouldn't be required to be used here. It's possible to get the same result via simple caching. select_related() is something entirely different. And the last reason this is different from select related: b = Blog.objects.get(id=1) for entry in b.entry_set.all(): entry.blog is b # There is no reason that this should not be True It makes sense for that to be True. For people unaware of what's going on, that should be True. For people assuming it's True, it should be. If the information's there for it to be True, and it's possible for it to be True, then shouldn't it be? That's why it's different. All tests still pass with the changes included. I wrote test cases. I added documentation. It's ready to be included just needs the okay. On Jan 29, 10:51 am, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > On 1/28/07 8:42 PM, [EMAIL PROTECTED] wrote: > > > i just wanted to spark some discussion of #3369. i implemented it and > > would like to see it get included. > > > here's an example of what reverse caching of foreign keys would mean: > > > b = Blog.objects.get(id=1) > > for entry in b.entry_set.all(): > > entry.blog # No database access required.How does this differ from > > select_related()? > > Jacob --~--~-~--~~~---~--~~ 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: Django tests failing under Python 2.3
On 1/29/07, Andrew Durdin <[EMAIL PROTECTED]> wrote: > > > On Jan 29, 4:50 pm, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On 1/29/07 10:15 AM, Robert Myers wrote: > > > > > I'm seeing the same amount of errors on python 2.3.4, it appears the @ > > > decorator syntax is being used in the modeltests/test-client/views.py. > > And I was so used to decorators that I didn't even pick up on that! > > A couple of tests use assertFalse / assertTrue which were introduced > to unittest in 2.4 also; these should be changed to failIf / > failUnless respectively. > > I couldn't figure out why one widget's test was giving a > UnicodeDecodeError while other extremely similar tests weren't... I have created a ticket for this error with a patch for assertFalse and assertTrue as you noted. http://code.djangoproject.com/ticket/3396 I'm still getting one error == FAIL: POST an empty dictionary to a view -- Traceback (most recent call last): File "/var/www/local/django/tests/modeltests/test_client/models.py", line 53, in test_empty_post self.assertEqual(response.status_code, 200) File "/usr/lib/python2.3/unittest.py", line 302, in failUnlessEqual raise self.failureException, \ AssertionError: 500 != 200 > > --~--~-~--~~~---~--~~ 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: Django tests failing under Python 2.3
On Jan 29, 4:50 pm, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > On 1/29/07 10:15 AM, Robert Myers wrote: > > > I'm seeing the same amount of errors on python 2.3.4, it appears the @ > > decorator syntax is being used in the modeltests/test-client/views.py. And I was so used to decorators that I didn't even pick up on that! A couple of tests use assertFalse / assertTrue which were introduced to unittest in 2.4 also; these should be changed to failIf / failUnless respectively. I couldn't figure out why one widget's test was giving a UnicodeDecodeError while other extremely similar tests weren't... --~--~-~--~~~---~--~~ 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: Critical ticket: can cause data loss
2007/1/29, James Bennett <[EMAIL PROTECTED]>: > > On 1/29/07, Ned Batchelder <[EMAIL PROTECTED]> wrote: > > I don't know that you need to make a release for this fix, but I think you > > should alert people to it. There is a mailing list for announcing releases > > and security issues, right? You should send a message to that list > > announcing the patch. > > I will once I've backported it. The question in my mind is just > whether we need 0.95.2 from this. I'm +1 on this option. Before making decision what about at least add a warning message on the documentation page? Cheers, David --~--~-~--~~~---~--~~ 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: Comments requested on two serializer related fixes
On Jan 29, 2007, at 5:22 AM, Russell Keith-Magee wrote: > > Hi All, > > I've just created two new tickets - #3389 and #3390. > > http://code.djangoproject.com/ticket/3389/ > http://code.djangoproject.com/ticket/3390/ These urls don't work with trailing slash, removing it works. Don --~--~-~--~~~---~--~~ 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: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Hi there,
I thank you for all your patience with me. I was completely off-track. I
read all the mails again, and everything is starting to make sense now.
This is going to be a lengthy email about #1356 and #3370, but please do
read until the end. Short executive summary: It's really a bug, and the
patch is not bad, but incomplete.
First, contrary to my former opinion, #3370 is a bug in the newforms
module, as it is passing unicode to the database API which is not ripe
for it and will break as soon as you leave ASCII. #3370 is independent
of #952.
I see three ways to fix the problem in #3370:
a) newforms stops passing unicode strings to the Database API and uses
bytestrings.
b) the database wrapper in Django sets connection.charset (but needs to
translate the charset name since the databases don't understand all
charset name variants, see ticket #952 here). This is the approach of
the patches in tickets #1356 and #3370.
c) the database wrapper in Djago must check whether it gets unicode. In
this case, it needs to encode it into a bytestring.
With all three variants, what encoding should be used? We currently
issue (without #952) a 'set name utf8' at the beginning of each
connection, so the database server expects to receive utf8. So,
shouldn't we currently always use utf8 encoding, regardless of what is
in settings.DEFAULT_CHARSET? This point has caused a lot of confusion.
Ivan wrote:
> I'm -1 on setting MySQL connection to 'utf8' in #3370. It *will* make
> sense when we will have newforms ready and models containing unicode.
> But now most of Django is a byte string country. A bright example are
> generic views that take data from web and store it to models without any
> conversions. This patch will feed 'windows-1251' or 'iso-8859-1' to
> MySQL saying that "it's utf-8" and MySQL will try to convert it and most
> certainly will store just strings of ''.
Well, the current patch in #3370 (I still ignore __repr__) only changes
the charset attribute of a connection, and this attribute is used only
to encode unicode strings when sending data to the database, or to
decode bytestrings received from the database when MySQLdb is configured
to produce unicode ('use_unicode'). Here's what the documentation in
MySQLdb-1.2.2b2 says:
use_unicode
If True, CHAR and VARCHAR and TEXT columns are returned as
Unicode strings, using the configured character set. It is
best to set the default encoding in the server
configuration, or client configuration (read with
==> read_default_file). If you change the character set after
==> connecting (MySQL-4.1 and later), you'll need to put the
==> correct character set name in connection.charset.
If False, text-like columns are returned as normal strings,
but you can always write Unicode strings.
*This must be a keyword parameter.*
(But, the charset parameter is also used when you pass in unicode
without setting use_unicode)
python-MySQLdb-1.2.1p2 is similar, only that there it is no keyword
parameter. There's an interesting difference between 1.2.1p2 and
1.2.2b2: For 1.2.1p2, you have to change the charset attribute of the
existing connection. If you try this on 1.2.2b2, it won't work. For
1.2.2b2, you either have to pass a 'charset' parameter when you create
the connection, or you can call a method set_character_set(). Both of
these won't work for 1.2.1p2, of course :-(
So, the APIs of python-MySQLdb are incompatible with each other (within
a minor version change!) This explains the differences between #1356 and
#3370. We need a patch that plays well with both versions of python-MySQLdb.
I don't see a problem with the generic views since they pass bytestrings
to the database wrapper, this gets as bytestrings to MySQLdb, and for
bytestrings the charset attribute is not used at all.
Of course, as soon as #952 has been applied, we need to use the encoding
from settings.DEFAULT_ENCODING.
Michael
P.S.:
If you set the charset parameter in 1.2.2b2's Connection.__init__(), the
default for use_unicode will be True, and python-MySQLdb will return
unicode strings.
--~--~-~--~~~---~--~~
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: Critical ticket: can cause data loss
On 1/29/07, Ned Batchelder <[EMAIL PROTECTED]> wrote: > I don't know that you need to make a release for this fix, but I think you > should alert people to it. There is a mailing list for announcing releases > and security issues, right? You should send a message to that list > announcing the patch. I will once I've backported it. The question in my mind is just whether we need 0.95.2 from this. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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: Critical ticket: can cause data loss
I think it is risky to assume that all potentially affected users will see this information in this thread. I found it, but there was an element of luck involved. I don't read this list religiously, and could easily have missed it. I don't know that you need to make a release for this fix, but I think you should alert people to it. There is a mailing list for announcing releases and security issues, right? You should send a message to that list announcing the patch. --Ned. Adrian Holovaty wrote: > On 1/25/07, James Bennett <[EMAIL PROTECTED]> wrote: > >> At the moment I'm leaning toward rolling 0.95.2 immediately after that >> goes in, but I'd like to hear opinions on it; with 0.96 probably >> coming up soon, I can come up with good arguments either way. >> > > Nah, given that generic relations have never been documented and the > small fraction of people using them probably all subscribe to this > mailing list, I don't see any point in having another release. Plus, > 0.96 is coming soon enough. > > Adrian > > -- Ned Batchelder, http://nedbatchelder.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: reverse caching of foreign keys #3369
On 1/28/07 8:42 PM, [EMAIL PROTECTED] wrote: > i just wanted to spark some discussion of #3369. i implemented it and > would like to see it get included. > > here's an example of what reverse caching of foreign keys would mean: > > b = Blog.objects.get(id=1) > for entry in b.entry_set.all(): > entry.blog # No database access required. How does this differ from select_related()? Jacob --~--~-~--~~~---~--~~ 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: Django tests failing under Python 2.3
On 1/29/07 10:15 AM, Robert Myers wrote: > I'm seeing the same amount of errors on python 2.3.4, it appears the @ > decorator syntax is being used in the modeltests/test-client/views.py. This > was introduced in python 2.4, I changed it to the old decorator syntax 'blah > = decorator(blah)' and still recieved 3 errors. So I haven't tried any > further. I've fixed the decorator usage in [4451] -- thanks for the heads up. Jacob --~--~-~--~~~---~--~~ 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: Django tests failing under Python 2.3
On 1/28/07, Andrew Durdin <[EMAIL PROTECTED]> wrote: > > > I'm trying to run all the django tests under Python 2.3.5 (on OS X > 10.4.8), and there are lots of failures (see below). > My settings file for the test is just: > > DEBUG = True > > DATABASE_ENGINE = 'mysql' # 'postgresql', 'mysql', 'sqlite3' > or 'ado_mssql'. > DATABASE_NAME = 'test' # Or path to database file if using > sqlite3. > DATABASE_USER = 'root' # Not used with sqlite3. > DATABASE_PASSWORD = '' # Not used with sqlite3. > DATABASE_HOST = '' # Set to empty string for localhost. > Not used with sqlite3. > DATABASE_PORT = '' # Set to empty string for default. Not > used with sqlite3. > > ROOT_URLCONF = None > > > Do these indicate something screwy with my setup, or do other 2.3.5 > users also get these? > > here's the test command and the full output: > > DJANGO_SETTINGS_MODULE=test_django.settings PYTHONPATH=~/django- > trunk:~/test_django ./tests/runtests.py > > == > ERROR: Request a page that is protected with @login, but use bad > credentials > -- > Traceback (most recent call last): > File "/Users/andy/Projects/django-trunk/tests/modeltests/test_client/ > models.py", line 101, in test_view_with_bad_login > self.assertFalse(response) > AttributeError: 'ClientTest' object has no attribute 'assertFalse' > > == > ERROR: Doctest: regressiontests.forms.tests > -- > Traceback (most recent call last): > File "/Users/andy/Projects/django-trunk/django/test/doctest.py", > line 2150, in runTest > failures, tries = runner.run( > File "/Users/andy/Projects/django-trunk/django/test/doctest.py", > line 1379, in run > return self.__run(test, compileflags, out) > File "/Users/andy/Projects/django-trunk/django/test/doctest.py", > line 1267, in __run > got += _exception_traceback(exc_info) > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position > 254: ordinal not in range(128) > > == > FAIL: POST an empty dictionary to a view > -- > Traceback (most recent call last): > File "/Users/andy/Projects/django-trunk/tests/modeltests/test_client/ > models.py", line 53, in test_empty_post > self.assertEqual(response.status_code, 200) > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/unittest.py", line 302, in failUnlessEqual > raise self.failureException, \ > AssertionError: 500 != 200 > > == > FAIL: GET a view that normally expects POSTs > -- > Traceback (most recent call last): > File "/Users/andy/Projects/django-trunk/tests/modeltests/test_client/ > models.py", line 45, in test_get_post_view > self.assertEqual(response.status_code, 200) > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/unittest.py", line 302, in failUnlessEqual > raise self.failureException, \ > AssertionError: 500 != 200 > > == > FAIL: GET a view > -- > Traceback (most recent call last): > File "/Users/andy/Projects/django-trunk/tests/modeltests/test_client/ > models.py", line 35, in test_get_view > self.assertEqual(response.status_code, 200) > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/unittest.py", line 302, in failUnlessEqual > raise self.failureException, \ > AssertionError: 500 != 200 > > == > FAIL: POST some data to a view > -- > Traceback (most recent call last): > File "/Users/andy/Projects/django-trunk/tests/modeltests/test_client/ > models.py", line 64, in test_post_view > self.assertEqual(response.status_code, 200) > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/unittest.py", line 302, in failUnlessEqual > raise self.failureException, \ > AssertionError: 500 != 200 > > == > FAIL: GET a URL that redirects elsewhere > -- > Traceback (most recent call last): > File "/Users/andy/Projects/django-trunk/tests/modeltests/test_client/ > models.py", line 74, in test_redirect > self.assertEqual(response.status_code, 302) > File
Re: Unicode or strings in models
Gábor Farkas wrote: > i think currently the "missing" thing is a decision from the "upper > level" :), about whether django-1.0 will be unicodized( unicodified?) or > not. Well... Given that newforms are all-unicode and already cause pain on unsuspecting developers it's either Django should follow them or they should be rewritten in byte-strings. Both tasks are hard but the former is better. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
reverse caching of foreign keys #3369
i just wanted to spark some discussion of #3369. i implemented it and would like to see it get included. here's an example of what reverse caching of foreign keys would mean: b = Blog.objects.get(id=1) for entry in b.entry_set.all(): entry.blog # No database access required. currently each item in the list would require a database access (which isn't needed). the one controversial change that i made is this. when you assign a value for a foreign key association, django sets the value, and clears it's cache. so this: entry = Entry.objects.get(id=1) blog = Blog.objects.get(id=1) entry.blog = blog entry.blog is blog # false entry.blog == blog # maybe true, maybe false is how things work currently. to some extent this makes sense. the entry hasn't been saved, so the value in the database is still potentially some other value. to me it makes more sense to update the cache rather than clearing the cache. my changes do just that, so the way it works is: entry = Entry.objects.get(id=1) blog = Blog.objects.get(id=1) entry.blog = blog entry.blog is blog # true entry.blog == blog # true doing this made implementing the reverse caching easier. all tests still pass, and i doubt it is something that anyone using django would notice. updating the cache is the way that i (and i imagine others) would expect things to work. so i hope that people like the reverse caching idea (the main point of this post) and don't mind the small implication that it has on other parts of 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: Comments requested on two serializer related fixes
Russell Keith-Magee wrote: > http://code.djangoproject.com/ticket/3389/ That thing: Article.authors = [4,7] is now done by Article.authors = [Author(id) for id in [4,7]] I.e. Author(id) creates some strange incomplete object that can be nonetheless used for m2m relations since only an id is needed. Would this suffice? --~--~-~--~~~---~--~~ 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: Comments requested on two serializer related fixes
On 1/29/07 7:22 AM, Russell Keith-Magee wrote: > I've just created two new tickets - #3389 and #3390. I'm +1 on #3390 (the ``DEFERRABLE INITIALLY DEFERRED`` bit); that makes a few other bulk-insert type tasks besides deserialization much easier. #3389 seems logical enough, but I'm a bit wary of TMTOWTDI syndrome here; the fact that:: article.author_set = [john, fred] and:: article.author_set = [john.id, fred.id] do the same thing seems a little weird. I guess I'd say I'm +0 unless anyone can think of a better way... Jacob --~--~-~--~~~---~--~~ 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: Unicode or strings in models
Ivan Sagalaev wrote: > Splitting this into new thread since it's already not about db client > encodings... > > ak wrote: >> So if everyone agreed, the way is simple: >> 1. when django loads data from db and fills in a model object, all >> strings have to be encoded according to DEFAULT_CHARSET >> 2. when django passes data from form object to model object, it has to >> encode strings according to DEFAULT_CHARSET again > > No, it would defeat the purpose of all this unicode endeavor. The point > is to work internally (view code, models code etc) on unicode objects > only. I'd rather propose this: > > - db backend decodes data from db into unicode > - all models' properties that are now str's should contain unicode all > the time (after reading from db and after assigning from forms) > - user would override __unicode__ of models instead of __str__ that is > used now > - a standard __str__ should be defined as: > > def __str__(self): >return unicode(self).encode(settings.DEFAULT_CHARSET) > > - model validation should call all models' __str__s and warn if they > return unicode objects > > I believe migration from __str__ to __unicode__ would as simple as a > search/replace operation. > > I apologies if this was already discussed and resolved. If yes, please > point me to where it was. i agree (well, i'm not sure if the migration will really be a search/replace, but the rest is ok). i think currently the "missing" thing is a decision from the "upper level" :), about whether django-1.0 will be unicodized( unicodified?) or not. gabor --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
raw_id_admin, move from "admin" to "forms"?
hi, (first i apologize if this was already discussed or solved. i could not find anything about it in the newsgroup-archives) i've seen that one of the latest commits did some changes to the "raw_id_admin" attribute. for the admin this is fine, but there is also an another aspect of raw_id_admin, which i'm not sure is addressed here: when the "oldforms" are used, raw_id_admin also affects them. when you use an automatic manipulator, then if you do not have raw_id_admin specified for a field, then when the post/get-data is manipulator-validated, then all the potential/possible foreign-keys are fetched. example: class A(Model): pass class B(Model): my_a = ForeignKey(A) (pseudocode, i didn't check if it's valid or not) now let's say i have 1 instances of A. now i call the AddManipulator for B. for validation, it will load in all the 1 instances of A. which is usually a bad thing. if i modify B as: class B(Model): my_a = ForeignKey(A, raw_id_admin = True) then it will do it the "reasonable" way. i understand the reason for getting all the 1 instances (so that the error-message produced by the manipulator can be "nice" and list all the possible "good" answers), but i would not recommend this to be the default-option. in other words: 1. imho it's good that raw_id_admin is moved out from the database-model into the admin-part. but also it is needed to be able to specify that in the 'automatic' form, i do want the raw_id_admin behavior. 2. it would be nice imho to make the raw_id_admin=True way the default. thanks, gabor --~--~-~--~~~---~--~~ 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: admin interface and CSS
Hello. Henry wrote: > I had a problem with CSS cause while the admin_media_prefix template > tag used the ADMIN_MEDIA_PREFIX setting, it did not prepend the > MEDIA_URL to it. I have all my static stuff, including CSS, on a > separate site so I was getting the admin interface without the good > looks. > > Either I did something wrong, or admin_media_prefix() in > contrib/admin/templatetags/adminmedia.py needs to have: > return settings.MEDIA_URL + settings.ADMIN_MEDIA_PREFIX > instead of > return settings.ADMIN_MEDIA_PREFIX As far as I can tell, django expects ADMIN_MEDIA_PREFIX to be an absolute url. Maybe you could file a ticket? BTW, a much better way to join urls would be: from urlparse import urljoin return urljoin(settings.MEDIA_URL, settings.ADMIN_MEDIA_PREFIX) -- Matias Hermanrud Fjeld --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
newforms: "forms with prefixes", nitpick
Am a latecomer to newforms, loving it. I have minor issue with the way prefixes are handled: http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/forms/tests.py#L2648 The prefix is prepended to the form names, which leads to some shortcomings, so add_prefix was created: http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/forms/tests.py#L2733 -1 Can we simple not take prefix to contain a formatting string? That is what came to my mind when I read prefix when I first encountered it. Is there something I am missing? -- Amit Upadhyay Blog: http://www.rootshell.be/~upadhyay +91-9820-295-512 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
