Re: ``models.BooleanField`` fields default to ``False`` when missing from fixtures
2012/9/24 Yo-Yo Ma > This may be the intended behavior, but I couldn't find docs on it. My > recommendation would defer to "The Zen of Python" > > In the face of ambiguity, refuse the temptation to guess. > > I would rather see the typical IntegrityError: Problem installing > fixture... Hello, This looks a lot like: https://code.djangoproject.com/ticket/15124 I hope I'll have time to study this problem again before the feature freeze of 1.5. -- Aymeric. -- 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.
Reminder: feature freeze for 1.5 in one week!
Hi folks -- A reminder: we're going into feature freeze for the 1.5 release on October 1st*, one week from today. This means that any features you want to get into 1.5 need to land this week. Practically, this means that if you don't have a patch/pull request open for review in the next day or two it's not going to happen: in the past, we've had some issues with not-quite-baked features landing at the last minute, so I'm going to be a bit more suspicious of anything that hasn't had at least a few solid days of review. So get those patches/pull requests up! Remember, though, that unlike past releases this won't constitute a trunk freeze, so anything that misses the deadline can go in when it's ready. Nothing needs to wait for the 1.5 release to go out the door. Also remember that this is feature freeze only; bug fixes still have a few more months until the final. Jacob [*] Timing-wise, it'll probably be closer to 10/3 than 10/1 given my travel schedule, but maybe not so don't count on! -- 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: ``models.BooleanField`` fields default to ``False`` when missing from fixtures
Yep, that looks like it. IMHO, this is a bug that should be fixed without delay, as it breaks a cardinal rule for Pythonistas, and could even lead to a "data corruption" situation, if a dev was to add a boolean field and forget to update a form or fixture, or both. On Monday, September 24, 2012 5:44:29 AM UTC-4, Aymeric Augustin wrote: > > 2012/9/24 Yo-Yo Ma > > >> This may be the intended behavior, but I couldn't find docs on it. My >> recommendation would defer to "The Zen of Python" >> >> In the face of ambiguity, refuse the temptation to guess. >> >> I would rather see the typical IntegrityError: Problem installing >> fixture... > > > Hello, > > This looks a lot like: https://code.djangoproject.com/ticket/15124 > > I hope I'll have time to study this problem again before the feature > freeze of 1.5. > > -- > Aymeric. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/6i5BdRrk8y0J. 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: ``models.BooleanField`` fields default to ``False`` when missing from fixtures
On Monday, September 24, 2012 3:07:37 PM UTC+2, Yo-Yo Ma wrote: > > Yep, that looks like it. IMHO, this is a bug that should be fixed without > delay, as it breaks a cardinal rule for Pythonistas, and could even lead to > a "data corruption" situation, if a dev was to add a boolean field and > forget to update a form or fixture, or both. > I don't see how that could corrupt stuff in the current situation, I'd rather argue that fixing the bug will cause more issues since people probably (I am sure I do) do unknowingly rely on the current behavior. As such we will exercise caution here and won't commit it in a rush just to get it in… Aside from that we obviously agree that it should get fixed ;) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/NAvUp-jYe9QJ. 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: ``models.BooleanField`` fields default to ``False`` when missing from fixtures
2012/9/24 Florian Apolloner > I don't see how that could corrupt stuff in the current situation, I'd > rather argue that fixing the bug will cause more issues since people > probably (I am sure I do) do unknowingly rely on the current behavior. As > such we will exercise caution here and won't commit it in a rush just to > get it in… Aside from that we obviously agree that it should get fixed ;) > Yes, thousands of sites must be relying on the current behavior. That's the reason why the bug isn't fixed yet. -- Aymeric. -- 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.
Model inheritance extended.
Hi everyone, 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 Cheers, Jonathan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/WIkRQuzDRCsJ. 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: ``models.BooleanField`` fields default to ``False`` when missing from fixtures
Developer of a pet shop software adds: feed_before_midnight = models.BooleanField() because they're planning on carrying baby gremlins... forgets to update the zoological XML feed importer to use the "feed_before_midnight" value, and the rest is history :) On Monday, September 24, 2012 9:21:34 AM UTC-4, Florian Apolloner wrote: > > ... > I don't see how that could corrupt stuff in the current situation > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/1bdXw5KfYRwJ. 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 Oracle backend vs. numbers
On Sunday 23 September 2012 15:05:21 Anssi Kääriäinen wrote: > > If you decide to work on this, please split the patch into two: one > for the ._rowfactory change, one for the feature addition. My belief > is that the ._rowfactory change is going to be something we can very > easily justify committing into 1.5, but the proposed feature addition > sounds like something which isn't as obvious. While preparing the patch, I ran into the inspectdb regression test suite; this suite includes, among other things, a model with a database column named 'prc(%) x', which breaks test database creation on Oracle on current trunk. I intend to include a fix for this (in a separate commit, of course) in the first part as well (doubling percent signs in quote_name()). -- 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: ``models.BooleanField`` fields default to ``False`` when missing from fixtures
On Tue, Sep 25, 2012 at 8:00 AM, Yo-Yo Ma wrote: > Developer of a pet shop software adds: > > feed_before_midnight = models.BooleanField() > > because they're planning on carrying baby gremlins... forgets to update the > zoological XML feed importer to use the "feed_before_midnight" value, and > the rest is history :) We need to be clear on what we (as in, the Django project) classify as "catastrophic data loss". Examples of Catastrophic data loss: * You request a save of object X, and object X is not saved. * You save object X, and object Y is modified. * You save object X, and object Z is deleted. NOT examples of Catastrophic data loss: * You forget to set a value on an object, and the default isn't what you expected. * You set a value on an object, which is saved verbatim, but wasn't the correct value under the circumstances. In the example you provide, I agree that there would be catastrophic consequences. However, the code is doing exactly what it's instructed to do. While I may concede that this is a bug, it's a bug caused by ambiguous default behaviour, not behaviour that is fundamentally incorrect or destructive -- it's essentially nothing more than "0 is a default value". You can argue that 0 isn't an appropriate default in this circumstance, but you can't argue that it is (a) a particularly surprising default, or (b) that the developer was given an opportunity (multiple opportunities, really) to set an appropriate default. If this conflicts with what you consider to be catastrophic, thats fine -- I'm just letting you know the benchmark that we, as a project, use to guide our decision making process. 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ``models.BooleanField`` fields default to ``False`` when missing from fixtures
The gremlin example was just a light-hearted attempt at justifying the claim of "data corruption", in response to Florian, but I really only brought up this issue because it surprised me (nothing in the docs). I would suggest a docs update to let developers know that if a default isn't set, ``False`` is implied - only because this seems like the sort of mini-"bug" that might never warrant fixing due to the ramifications. On Monday, September 24, 2012 9:18:34 PM UTC-4, Russell Keith-Magee wrote: > > On Tue, Sep 25, 2012 at 8:00 AM, Yo-Yo Ma > > wrote: > > Developer of a pet shop software adds: > > > > feed_before_midnight = models.BooleanField() > > > > because they're planning on carrying baby gremlins... forgets to update > the > > zoological XML feed importer to use the "feed_before_midnight" value, > and > > the rest is history :) > > We need to be clear on what we (as in, the Django project) classify as > "catastrophic data loss". > > Examples of Catastrophic data loss: > * You request a save of object X, and object X is not saved. > * You save object X, and object Y is modified. > * You save object X, and object Z is deleted. > > NOT examples of Catastrophic data loss: > * You forget to set a value on an object, and the default isn't what > you expected. > * You set a value on an object, which is saved verbatim, but wasn't > the correct value under the circumstances. > > In the example you provide, I agree that there would be catastrophic > consequences. However, the code is doing exactly what it's instructed > to do. While I may concede that this is a bug, it's a bug caused by > ambiguous default behaviour, not behaviour that is fundamentally > incorrect or destructive -- it's essentially nothing more than "0 is a > default value". You can argue that 0 isn't an appropriate default in > this circumstance, but you can't argue that it is (a) a particularly > surprising default, or (b) that the developer was given an opportunity > (multiple opportunities, really) to set an appropriate default. > > If this conflicts with what you consider to be catastrophic, thats > fine -- I'm just letting you know the benchmark that we, as a project, > use to guide our decision making process. > > Yours, > Russ Magee %-) > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/YO9PTOVrakUJ. 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.
DatabaseFeatures and supports_transactions
Hi, DatabseFeatures class has a supports_transactions property for test if the db engine support transactions. supports_transactions implementation makes some metadata alters to check this behaivor. Now, is really needed to do this to check transaction support? I don't know exactly how many times this supports_transactions is called but I think what it produce unnecessary alterations in database structure, or I'm misinterpreting how it supposed works. --- Maxi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/J4kOjty-FHkJ. 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.
