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. Also instead of using eval, I would take a look at the operator module, and use operator.add, etc... . The second test failure looks to be caused by something being changed in the ORM, unfortunately, I'm not sure what caused it.
Alex On May 22, 3:01 pm, Sebastian Noack <[EMAIL PROTECTED]> wrote: > On Wed, 21 May 2008 21:12:05 +0800 > > > > "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > > What do I think? The code doesn't look fundamentally bad, but I'm not > > going to take a serious look until there are some test cases. > > > Consider this from my point of view. I need to validate that your code > > works as advertised. As your patch currently stands, I need to write > > my own test cases, including coming up with some models, some test > > data, and thinking about the edge cases that need to be checked. This > > takes time - time that could be spent looking at someone else's code, > > merging someone else's patch. Given that my time is limited, and there > > are multiple demands on my time, it makes sense for me to concentrate > > on those patches that make my life easy, and enable me to process as > > many tickets as my limited time allows. > > > Like I said last time, test cases are how you prove you are serious. > > It's how you prove to me that you've done more than a trivial analysis > > of the problem. It's how you prove to me that you've considered the > > edge cases. And for your own sanity, it's how you prove to yourself > > than when you make one of those "minor, this couldn't possibly affect > > anything" changes, that it actually doesn't change anything. > > I know that tests are essential and if you look at the ticket, you will > see that I have added a new version of my patch including doc tests. ;) > > I know what you think about patches adding new functionality but don't > providing test cases. And I completely agree. But you should see my > previous patches on this ticket just as proof of concept to help as to > discuss the functionality, its implementation and API. > > During writing the tests i came up with a few bugs and fixes: > > (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. > > (2) I ensured that when using update(), get_db_prep_save() is called. > get_db_prep_lookup() is called anyway, but for example when using > DateTimeField and MySQL, get_db_prep_save() (as opposed to > get_db_prep_lookup) truncates microseconds because of missing support > in MySql of microseconds, so this must be done also on update. > > (3) I added a sanity check to update(), preventing updating sliced > query sets, because of calling update() on a sliced query set will > update all objects. Do not think about implemeting this feature. > Although some DBMS might supports UPDATE with LIMIT and OFFSET, many > don't or support only LIMIT (as MySQL for example). > > Note that (2) and (3) are bugs not introduced, but fixed by my patch. > Another reason for merging it. ;) > > Regards > Sebastian Noack > > signature.asc > 1KDownload --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
