Ticket #7299: XViewMiddleware dependency issue
Hi. Can anyone let me know why XViewMiddleware (django.middleware.doc.XViewMiddleware) have dependency on auth subsystems? I reported this issue, and submitting a patch, but it has been marked "wontfix". http://code.djangoproject.com/ticket/7299 I think XViewMiddleware does not need auth subsystems. It should work with settings.INTERNAL_IPS only, like django.core.xheaders (django.core.xheaders checkes whether auth subsystems is enabled, or not). Thanks. --~--~-~--~~~---~--~~ 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: Partial Models Discussion
On May 23, 2:29 pm, "Gary Wilson Jr." <[EMAIL PROTECTED]> wrote: > However, one of the benefits of values() returning a dict is that you > avoid the more expensive model instance creation when you don't need it. I wouldn't be so quick to assume that creating model instances (or ducks that look like them) is so bad. I did some quick-and-dirty profiling (Python 2.5.2, Pentium M) for 3 scenarios: making a normal class instance, making a dict, and making a class with __slots__. I put two data fields on each. The results, after running timeit several times to get stable results, are neck-and-neck: normal class instance: 1.34 microseconds per instantiation dict: 1.04 us class with __slots__: 1.07 us Granted, I'm not creating model instances. The model __init__ is expensive, but unnecessary in this case *if* you avoid dispatching signals. (Just call ModelClass.__new__(ModelClass).) So theoretically we could make full model instances in barely more time than making dicts. There's a little complexity in what to do about items you haven't retrieved. Pseudocode to solve that: class LazyLookupDescriptor(object): def __init__(self, name): self.name = name def __get__(self, instance, owner): return do_real_db_lookup(instance, name) # and cache on the instance. def __set__ # ... you get the idea. def values_returning_models(): tmpclass = ModelBase(name, (model_class,), attrs) # would need to ensure abstract, maybe add __slots__, etc. tmpclass_new = tmpclass.__new__ for field in hidden_fields: setattr(tmpclass, field, LazyLookupDescriptor(field)) for row in db_iter: obj = tmpclass_new(tmpclass) obj.__dict__.update(row) # or something like that yield obj Alternately, the __get__ could set instance.__class__ to the real model class and opportunistically fill in all of the rest of the data (and log an info message that we're doing that). Pulling in selected attributes from related objects is going to be more painful, though... dict easily wins there. But when I tried using the model __new__ and then setting attributes, it took 2.04 us; I can't figure out why it's that much slower. As for signals, maybe we do these optimizations only if no signal handlers are registered. Hope this is helpful; apologies if this has all been brought up before and I missed it. -Ken --~--~-~--~~~---~--~~ 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: Partial Models Discussion
Nope it's just something I was throwing around.
What would exclude do in that example? I feel it should be explicit rather
than implicit (although I do see the reason for implicit calls where you
don't want to return text/blob fields, but explicit is always better).
On Fri, May 23, 2008 at 3:18 PM, Gary Wilson Jr. <[EMAIL PROTECTED]>
wrote:
>
> David Cramer wrote:
> > IMO show() and hide() are extremely ugly. And I think .values() is
> becoming
> > ugly with the addition of values_tuple or whatever it's called. I don't
> see
> > a real good reason to clutter the namespace even more than it already is.
> > I'd rather have .values(type=dict) or something similar.
>
> Sorry, for some reason I completely skipped over the type switching in
> the values() call. I do agree that it would be better than having
> separate methods for each.
>
> I wonder if we would also need to support the people who want to exclude
> fields:
>
> Model.objects.values('field1', 'field2', exclude_fields=[...], type=...)
>
> Has a discussion of something like the "type" keyword argument been
> brought up before? The only two threads [1][2] I found about
> valuelist() and value_list() don't mention the idea.
>
> Gary
>
> [1]
>
> http://groups.google.com/group/django-developers/browse_frm/thread/22b44f4eafaf956a/
> [2]
>
> http://groups.google.com/group/django-developers/browse_frm/thread/4c7ba291577e6e73/
>
> >
>
--
David Cramer
Director of Technology
iBegin
http://www.ibegin.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: Partial Models Discussion
David Cramer wrote:
> IMO show() and hide() are extremely ugly. And I think .values() is becoming
> ugly with the addition of values_tuple or whatever it's called. I don't see
> a real good reason to clutter the namespace even more than it already is.
> I'd rather have .values(type=dict) or something similar.
Sorry, for some reason I completely skipped over the type switching in
the values() call. I do agree that it would be better than having
separate methods for each.
I wonder if we would also need to support the people who want to exclude
fields:
Model.objects.values('field1', 'field2', exclude_fields=[...], type=...)
Has a discussion of something like the "type" keyword argument been
brought up before? The only two threads [1][2] I found about
valuelist() and value_list() don't mention the idea.
Gary
[1]
http://groups.google.com/group/django-developers/browse_frm/thread/22b44f4eafaf956a/
[2]
http://groups.google.com/group/django-developers/browse_frm/thread/4c7ba291577e6e73/
--~--~-~--~~~---~--~~
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: Want to have unit tests in multiple files
On Fri, 23 May 2008 13:32:45 -0500
"Gary Wilson Jr." <[EMAIL PROTECTED]> wrote:
> In case you haven't figured this out already, it can be done by
> importing your unit test classes from the test/*.py modules in
> tests/__init__.py
That is exactly what I have done at my work, just a few days ago. I
put the code below into the tests/__init__.py. You can use it as is.
def get_test_modules():
from os import path, listdir
names = set()
for f in listdir(path.dirname(__file__)):
if f.startswith('.') or f.startswith('__'):
continue
names.add(f.split('.')[0])
for name in names:
yield (name, __import__('%s.%s' % (__name__, name), {}, {}, ['']))
def setup_doc_tests():
for name, module in get_test_modules():
# Try to find an API test in the current module, if it fails continue.
try:
api_tests = module.__test__['API_TESTS']
except (AttributeError, TypeError, KeyError):
continue
# Import possible dependecies of the API test from the current module.
for k, v in module.__dict__.iteritems():
if k.startswith('__'):
continue
globals()[k] = v
# Attach the API test to the __test__ dictionary if it exists or create
it.
try:
globals()['__test__'][name] = api_tests
except KeyError:
globals()['__test__'] = {name: api_tests}
def setup_unit_tests():
import unittest
for name, module in get_test_modules():
# Import each TestCase from the current module.
for k, v in module.__dict__.iteritems():
if not (isinstance(v, type) and issubclass(v, unittest.TestCase)):
continue
globals()[k] = v
setup_doc_tests()
setup_unit_tests()
signature.asc
Description: PGP signature
Re: Partial Models Discussion
IMO show() and hide() are extremely ugly. And I think .values() is becoming ugly with the addition of values_tuple or whatever it's called. I don't see a real good reason to clutter the namespace even more than it already is. I'd rather have .values(type=dict) or something similar. On Fri, May 23, 2008 at 1:29 PM, Gary Wilson Jr. <[EMAIL PROTECTED]> wrote: > > David Cramer wrote: > > I'd like to present my concept for partial models, which would be an > > attempt to replace the use of .values() returning a dictionary > > (although .values() still has uses if you dont actually want an > > instance). Keep in mind, the way I'm presenting this would keep #17 > > working :) > > > > values, values_tuple, and partial models, in my opinion, should all be > > replaced with one method call (what if theres a values_list or > > values_set, seems ugly). This would become a new values method: > > > > values(results=[object|tuple|dict]) or something similar > > > > Upon returning the object, you would get proxies, which held a model > > instance in it. > > However, one of the benefits of values() returning a dict is that you > avoid the more expensive model instance creation when you don't need it. > So I lean more towards something like #5420 rather than changing what > values() returns. > > And, if you would rather be explicit in the positive tone, then maybe a > show() method to complement the hide() would satisfy you. > > Gary > > > > -- David Cramer Director of Technology iBegin http://www.ibegin.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: Want to have unit tests in multiple files
Alex Koshelev wrote: > No. Not `tests.py`, but `tests` module - that can be a package of many > other modules/files In case you haven't figured this out already, it can be done by importing your unit test classes from the test/*.py modules in tests/__init__.py Gary --~--~-~--~~~---~--~~ 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: Add optional FOR UPDATE clause to QuerySets
On Sat, 17 May 2008 13:04:36 +0200 Sebastian Bauer <[EMAIL PROTECTED]> wrote: > Thank you for answer, but for update, i think, is really important > for commercial projects and places where you need to be sure that no > one changed row in parallel I don't think that commercial projects have an exceptional position. But if FOR UPDATE is important for your project, you can use the patch as Russel already told you. But if the only thing you want to do is to ensure that data aren't changed between several SQL statements you can go with transactions, which are supported very well, by django at the moment. Regards Sebastian Noack signature.asc Description: PGP signature
Re: Bug (very mild) in PostgreSQL version _check_
Haroldo Stenger wrote: > I think I've found a bug in Django and a solution :-) Please file a ticket [1] (after searching first [2]) for this issue if you haven't already so that it's not forgotten. [1] http://code.djangoproject.com/simpleticket [2] http://code.djangoproject.com/query Thanks, Gary --~--~-~--~~~---~--~~ 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: #7295: quotes, escaping and translation of string literals in templates
I haven't looked at what your doing real close, but it seems to me your trying to re-implement the shlex module [1] which has been in the Python standard library since 1.5.2. Will that do the trick? [1]: http://docs.python.org/lib/module-shlex.html On Fri, May 23, 2008 at 10:56 AM, akaihola <[EMAIL PROTECTED]> wrote: > > It's confusing that the django.utils.text.smart_split() function un- > escapes quotes and backslashes inside the literal string while > preserving the surrounding quotes: > >>>> print ' '.join(smart_split(ur'arg1 "the \"second\" argument" > "the \\third\\ argument"')) >arg1 "the "second" argument" "the \third\ argument" > > I would find it simpler to just have either > 1) escaped and quoted literal strings, or > 2) un-escaped and un-quoted strings. > > This would also make it simpler to unify the handling of variables and > filter expressions in django/template/__init__.py. > > > -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #7295: quotes, escaping and translation of string literals in templates
It's confusing that the django.utils.text.smart_split() function un- escapes quotes and backslashes inside the literal string while preserving the surrounding quotes: >>> print ' '.join(smart_split(ur'arg1 "the \"second\" argument" "the \\third\\ argument"')) arg1 "the "second" argument" "the \third\ argument" I would find it simpler to just have either 1) escaped and quoted literal strings, or 2) un-escaped and un-quoted strings. This would also make it simpler to unify the handling of variables and filter expressions in django/template/__init__.py. --~--~-~--~~~---~--~~ 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: Manager-model reassignment on abstract subclassing
Because of I needed the patch more urgent I actually thought by myself, I have already uploaded a new version including test cases. I found a bug by the way, that breaks the ability to derive from a not abstract model, but I have fixed it. If you are already using the previous version of my patch, you should update now. I think the patch is ready to get merged into trunk now, but I can not decide this. What does the maintainers think? Regards Sebastian Noack signature.asc Description: PGP signature
Re: Multiple database support
On 23 mayo, 13:00, "Mike Scott" <[EMAIL PROTECTED]> wrote: > > Maybe having to state a storage location on a per-row level. (IE this could > happen by overriding the manager, and simply switching DB at selection time. > or being able to provide the DB info at selection time.) Maybe i good thing was to provide a middleware that does db selection. Think in applications user centered. In those, user define what DB use. You can provide an API for change DB of all next queries, and use if you want in a middleware (looking at request.user). --~--~-~--~~~---~--~~ 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: Multiple database support
On May 22, 6:53 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > Simon Willison wrote: > > Thankfully Ivan Sagalaev's confusingly named mysql_cluster > > BTW does anyone have a suggestion how to rename it? I've picked > mysql_cluster simply because I didn't know that there exists the thing > named "MySQL Cluster" (no kidding :-) ). How about mysql_masterslave or mysql_replicated (I prefer the second)? --~--~-~--~~~---~--~~ 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: Multiple database support
You need to be aware that this is quite complicated if your model has foreign keys in it: if you use the ORM to do queries, the ORM would have to be so smart as to when to split up your queries instead of doing joins. eg you have model A which foreign keys to a User model. For a row of A that is in the same database as User, the ORM could simply use a join, but for a row of A that was already in the other database, it can't. I do not believe this is a trivial change. My proposal is to keep things simple in a first phase: let's make it possible to use different databases for different models with the restriction that relations should not cross databases. Once we get all that working, we may look at making the query generation deal with those. Koen On 23 mei, 13:00, "Mike Scott" <[EMAIL PROTECTED]> wrote: > On Fri, May 23, 2008 at 2:59 AM, Simon Willison <[EMAIL PROTECTED]> > wrote: > > > 1. Replication - being able to send all of my writes to one master > > machine but spread all of my reads over several slave machines. > > Thankfully Ivan Sagalaev's confusingly named mysql_cluster covers this > > problem neatly without modification to Django core - it's just an > > alternative DB backend which demonstrates that doing this isn't > > particularly hard:http://softwaremaniacs.org/soft/mysql_cluster/en/ > > Personally I think this is something that is better solved by the database > software itself. Having replication code-side is something that I don't feel > to good about. But maybe thats just me. > > > > > 2. Sharding - being able to put User entries 1-1000 on DB1, whereas > > User entries 1001-2000 live on DB2 and so on. > > This is something I would love, an example being archives. (As Eratothene > points out. > > Maybe having to state a storage location on a per-row level. (IE this could > happen by overriding the manager, and simply switching DB at selection time. > or being able to provide the DB info at selection time.) --~--~-~--~~~---~--~~ 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: QuerySet.update improvement.
On Fri, 23 May 2008 17:20:43 +0800 "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > I'm currently sitting in an airport, so I won't have a chance to have > a good look until tomorrow at the earliest. However, here's some > immediate feedback. Most of them are in the category of "this probably > works, but they need tests to prove it": > > - What about references to forieign keys? (e.g., Company has a CEO > and a pointOfContact, both of which are people; make the CEO the point > of contact) This will work, because of a foreign key is just an integer in the database, which are covered by the tests I have written. But I don't think that a separate test case is required for this use case. > - What about date fields? (increase the 'next_contact_date' by a > week) The tests ensure that the corresponding SQL is created as it works for integers and floats. The only reason why it could fail is, when the used DBMS does not support the operator for the given type (in this case timestamp). And if the DBMS don't support the used operator for the corresponding column type, I think it is ok, that a database error is raised. I would like to not implement DBMS dependent switches to handle column types as varchar. As far as I know timestamp will work, but if not it is only because of missing support of the underlying DBMS. > - I can see lots of use of F() in update() clauses, but what about > filter()? (give me all the companies where the number of employees is > greater than the number of chairs owned. Don't worry about doing this > with aggregates - just keep n_chairs and n_employees as attributes) I don't found such a use case, when I wrote the tests, but I would like to add such a test case. Thanks for the example. > - What about F() using joins? This may be outside the scope of what > is easily possible, and I'd be happy to defer this till later, but it > would be interesting if you could populate a field based upon a joined > column. This isn't possible at the moment. But I also think that it is outside of the current scope. I would like to implement it later (when the patch with the given features is merged), too. > > (1) I figured out that <<, >> (left and right shift) and ~ > > (inversion) is (at least in MySQL) not supported, when selecting > > from tables. So I decided to drop support for this corner case. > > This doesn't particularly concern me. I'm having a hard time thinking > of an occasion where I would need those operators. Me too. I just added it because of completeness. But I dropped it as soon I noted that it is badly supported by MySQL (and probably other DBMS, too). > > Note that (2) and (3) are bugs not introduced, but fixed by my > > patch. Another reason for merging it. ;) > > These second two points are bug fixes that are independent of this > ticket. The large feature described by #7210 might take a little while > to get into trunk; obvious bug fixes should be applied as soon as > possible. It helps us to keep the commits atomic, so we can tell > exactly what changes (and why) with each commit. Please open tickets > for each of these problems (if there aren't already tickets), and > split the parts of the #7210 patch that fix those issues (and the > relevant tests) into separate patches. I think you are right about (3). But (2) is not a fatal bug, but rather a corner case and handled deep into the new code. Regards Sebastian signature.asc Description: PGP signature
Re: #7295: quotes, escaping and translation of string literals in templates
The django.utils.text.smart_split() function used to split template
tag contents seems to strip backslashes. On the other hand, string
literals in variables (like {{"mystring"}}) are passed to the filter
expression parser with backslashes intact.
This complicates things a bit. Forget the part about passing all unit
tests for now...
--~--~-~--~~~---~--~~
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: {GSoC 2008}Django-Newcomments : A preview
On 22 touko, 18:47, "Nicolas Lara" <[EMAIL PROTECTED]> wrote: > objet it refers since I dont see any case in which it would make sense > to have the replies away from the objects being replied upon. I've experimented with both approaches on a couple of websites, and the "correct" solution depends on * the number of comments in a single topic * the frequency of new comments vs. active participants' visit frequency On low-traffic sites I've found it much more usable to sort comments chronologically with no thread indentation. I usually include a running comment number and the number of the parent comment, which is also linked to the parent comment's HTML achor. This approach is similar to Trac's ticket system. So it would be great to have the flexibility to make both approaches possible. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
#7295: quotes, escaping and translation of string literals in templates
While I was trying to implement allowing filter expressions as
arguments to some built-in template tags (see #5756), I found
inconsistencies in the handling of literal strings in the template
system.
Collin Grady's patch [1] for {% ifequal %} looks good, but using the
same logic for other tags causes unit tests to fail. The reason is
that the FilterExpression class [2] (called by compile_filter()) only
accepts double quoted string literals, whereas tests generally use
single quoted strings. The current implementations of several template
tags resolve their arguments using the Variable class [3], which turns
out to handle both single and double quoted strings.
After studying the code for filter expression and variable resolution
I came up with a patch suggestion [4] for allowing single quotes in
filter expressions. I also made sure that escaping of the chosen quote
character and the backslash character works correctly. I also re-
factored the FilterExpression and Variable classes a bit so they use
the same code to unquote and un-escape string literals.
In FilterExpression this change required a different approach to the
filter_re regular expression. Single and double quoted translated and
un-translated strings are now all caught with a single group and
parsed further in the Python code. I have not yet looked into
performance effects or possible optimizations of this implementation.
I couldn't find any design desicions wrt single and double quotes. But
if there is a decision against single quotes, of course an entirely
different approach has to be taken.
All current unit tests pass with the suggested patch. The patch is
attached to #7295.
#5756 http://code.djangoproject.com/ticket/5756
#7295 http://code.djangoproject.com/ticket/7295
[1] http://code.djangoproject.com/attachment/ticket/5756/5756.patch
[2]
http://code.djangoproject.com/browser/django/trunk/django/template/__init__.py#L459
[3]
http://code.djangoproject.com/browser/django/trunk/django/template/__init__.py#L595
[4] http://code.djangoproject.com/attachment/ticket/7295/7295.1.diff
--~--~-~--~~~---~--~~
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: Multiple database support
On Fri, May 23, 2008 at 2:59 AM, Simon Willison <[EMAIL PROTECTED]> wrote: > 1. Replication - being able to send all of my writes to one master > machine but spread all of my reads over several slave machines. > Thankfully Ivan Sagalaev's confusingly named mysql_cluster covers this > problem neatly without modification to Django core - it's just an > alternative DB backend which demonstrates that doing this isn't > particularly hard: http://softwaremaniacs.org/soft/mysql_cluster/en/ Personally I think this is something that is better solved by the database software itself. Having replication code-side is something that I don't feel to good about. But maybe thats just me. > > > 2. Sharding - being able to put User entries 1-1000 on DB1, whereas > User entries 1001-2000 live on DB2 and so on. > > > This is something I would love, an example being archives. (As Eratothene points out. Maybe having to state a storage location on a per-row level. (IE this could happen by overriding the manager, and simply switching DB at selection time. or being able to provide the DB info at selection time.) --~--~-~--~~~---~--~~ 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: QuerySet.update improvement.
> I'm testing on SQLite, and I don't get that failure when running on > vanilla trunk. I am sorry. You was right, but I have fixed it. > > > I just updated to your latest patch and there appears to be 2 test > > > failures:http://dpaste.com/52137/, the first one appears to be > > > caused by the fact that different database engines do the rounding > > > differently, my suggestion would be to change to something that > > > divides evenly for the integer value. I changed the tests, that the results aren't something like *.5 anymore, which might become rounded up- or downwards depending on the db engine. The result of the division test is 2.8 now. This should actually work. Furthermore I am using the operator module instead of eval, now. Thanks for this advice. I just forgot that I can use it for this test. Regards Sebastian Noack signature.asc Description: PGP signature
