Re: Changing deferred model attribute behavior
On 29 huhti, 00:09, ptone wrote: > A couple just quick observations. > > defer and only are tasks/concepts used when doing a query based on > knowledge of your dataset - adding them to the model itself expands the > number of places where this concept is considered. This has some good and > some bad. > > What happens if you have defined a group on a model, and use only a single > field for 'only' in a QS? Does it fetch the only one I've asked for, or > does it trigger the group? > > Why couldn't one just defined the group in the code using .only() and pass > all the fields at the time you want. > > In Adrian's case, there will always be at least 2 DB hits - one could > define the group of "lazy fields" and do something like: > > >>> u = User.objects.only(*lazygroup).get(id=u.id) > > I guess for something like that to be more practical, we need to expose > something on the model instance that makes it easy to see what fields are > currently deferred? Something that could easily check whether the second > load had been done, and the lazy fields were available or not. > > These are mostly observations, I'm not against adding the idea of groups to > the model definition, but do think that if it can be solved at the scope of > the QS usage, where .only() and .defer() currently are used, that would be > better - one less reason to check the model definition to see how it was > set up. How about taking a different approach? If a Model.refresh(*fields) method is introduced and if deferred loading happens through instance.refresh(), then by overriding the method you can alter the deferred loading strategy in any way you wish. In addition, if refresh() takes an all_deferred kwarg, then the original problem can be solved in this way: def refresh(self, *fields, **kwargs): kwargs['all_deferred'] = True super(User, self).refresh(*fields, **kwargs) There are other use cases where model.refresh() would be useful. The currently recommended way to refresh an instance is to do obj = SomeModel.objects.get(pk=obj.pk), but this doesn't work nicely in all cases. While having Meta.deferred_groups or QuerySet.only(*fields, loadall=True/False) would be a bit nicer API, I am still of the opinion that use cases where it actually matters how deferred loading happens are rare. The above gives a way to customise deferred loading strategy. For the concrete use cases I have seen so far overridden .refresh() should be enough. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
design decisions for django-mssql: (switching on autocommit and remote proxy) advice wanted.
Dear knowledgeable persons: I have completed a beta-test version of a Linux remote access server for adodbapi, and have started the process if integrating them into django-mssql. (This is going to be an interesting experience for me -- I have already identified two or three new features that adodbapi needs to have.) I would like to get your collective wisdom about how to best accomplish two things. 1) The transaction logic will change drastically for django 1.6. For the supported backends it makes good sense to simply change that in the repository. However, it is reasonable to expect significant code change with the upgrade of this backend, and I think that we should maintain a single code base for a while. I was thinking of behavior similar to what I do inside of adodbapi: ...if sys.version_info >= (3,0): # note that the "if" is executed at import time, not run time. ..maxint = sys.maxsize ...else: ..maxint = sys.maxint Is there something more appropriate than django.VERSION to use for this, or is it, perhaps, just a bad idea? 2) In my unit test programs, I detect whether to use the proxy module or the regular module depending on whether their is a certain key in the connection arguments. .. import adodbapi ...import adodbapi.remote ...if "proxy_host' in connection_keywords: ..db = adodbapi.remote ...else: ..db = adodbapi ...db_connection = db.connect(connection_keywords) Would there be any technical or political reasons NOT to do that in sqlserver_ado/base.py ? -- Vernon Cole -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [GSoC 2013] Revamping validation functionality proposal
> > On Mon, Apr 29, 2013 at 6:25 AM, Christopher Medrela > wrote: > > Jacob, as you said, I deleted django-updates part, but I ended with a > > proposal taking only 9 weeks. Did you mean also scheduling more than 6 > weeks > > for the first part of the proposal (writing the new framework) and > > "stretching" the schedule to 12 weeks? I agree that 6 weeks for writing > the > > framework is slightly too few, but on the other side we have to send > > evaluations after first six weeks, so I think it's a good idea to have > > something that works done. > > Look, it's up to you; my goal is to encourage you to come up with a > plan that's realistically deliverable. Nearly ever summer of code > student so far has overestimated how much they can get done. So I'm > trying to help you come up with a proposal that matches what you can > actually do. Don't forget to take Hofstadter's Law > (http://en.wikipedia.org/wiki/Hofstadter%27s_law) into account! > > Ultimately, we're much more likely to reject an overly-ambitious > proposal than an underly-ambitious one. Our goal is to see you get > done what you promise to get done, so that starts with having > realistic expectations. > > Jacob > I looked deeper into what I have to do and reestimated my proposal. And you're right -- the result is that the first part (introducing the new validation framework) will take more time (about 8 weeks instead of 6). Merging django-secure will take one week longer. The proposal is still available here [1]. I rewritten "schedule and milestone" part -- that was mainly adding more details, so there is no need to review it again. I've published my proposal as a gist. Can I point to it in the submit proposal form? Repasting it and formatting again might be boring job. [1] https://gist.github.com/chrismedrela/82cbda8d2a78a280a129 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: design decisions for django-mssql: (switching on autocommit and remote proxy) advice wanted.
On Tuesday 30 April 2013, VernonCole wrote: > Dear knowledgeable persons: > > I have completed a beta-test version of a Linux remote access server for > adodbapi, and have started the process if integrating them into > django-mssql. (This is going to be an interesting experience for me -- I > have already identified two or three new features that adodbapi needs to > have.) I would like to get your collective wisdom about how to best > accomplish two things. > > 1) The transaction logic will change drastically for django 1.6. For the > supported backends it makes good sense to simply change that in the > repository. However, it is reasonable to expect significant code change > with the upgrade of this backend, and I think that we should maintain a > single code base for a while. I was thinking of behavior similar to what I > do inside of adodbapi: > > ...if sys.version_info >= (3,0): # note that the "if" is executed at > import time, not run time. > ..maxint = sys.maxsize > ...else: > ..maxint = sys.maxint > > Is there something more appropriate than django.VERSION to use for this, or > is it, perhaps, just a bad idea? > I work with a company who uses Django with MSSQL, and traditionally stays behind Django releases (e.g. we moved to 1.4 only around the release of 1.5). For us to be using this in the next two years, I'd say that this kind of backwards-support is a must. > 2) In my unit test programs, I detect whether to use the proxy module or > the regular module depending on whether their is a certain key in the > connection arguments. > > .. import adodbapi > ...import adodbapi.remote > > ...if "proxy_host' in connection_keywords: > ..db = adodbapi.remote > ...else: > ..db = adodbapi > ...db_connection = db.connect(connection_keywords) > > Would there be any technical or political reasons NOT to do that in > sqlserver_ado/base.py ? > It isn't quite clear to me how this would reflect in user code. If (as I suspect) this is just another key in the OPTIONS dictionary inside the DATABASES entry, then it's perfectly ok. We have to use different entries for Linux and Windows anyway. HTH, Shai. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Django 1.6 release timeline
Hi folks - Unless there are strong objections, here's what I'm thinking for the Django 1.6 release timeline: Alpha: May 16 Beta: June 20 RC: Aug 1 Final: as early as Aug 8, or later if more RCs are needed. Remember that Alpha is the deadline for "big" features, so if you've got something sizable that you want to get into 1.6 you'll need to have it done in a couple of weeks. If it's really awesome but you need more than a couple weeks, I *might* be convinced to push the deadline back just a little bit, but please speak up now. 1.6 won't be a huge release -- the new transaction management is the biggest feature -- but I'd like to get a release out this summer. That paves the way for work being done over the summer -- Summer of Code and Andrew's migration work -- to land shortly after 1.6 and ship as part of 1.7 in early in 2014. So yeah, objections if you've got 'em, otherwise we'll roll with this. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django 1.6 release timeline
On Apr 30, 2013, at 3:31 PM, Jacob Kaplan-Moss wrote: > Hi folks - > > Unless there are strong objections, here's what I'm thinking for the > Django 1.6 release timeline: > > Alpha: May 16 > Beta: June 20 > RC: Aug 1 > Final: as early as Aug 8, or later if more RCs are needed. Sounds reasonable. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Django 1.6 release timeline
On Tuesday 30 April 2013, Jacob Kaplan-Moss wrote: > Hi folks - > > Unless there are strong objections, here's what I'm thinking for the > Django 1.6 release timeline: > > Alpha: May 16 > Beta: June 20 > RC: Aug 1 > Final: as early as Aug 8, or later if more RCs are needed. > I see one issue with this: According to current procedures, if this timeline is followed, support for 1.4 will be dropped less than 6 months after the release of 1.5. At least for some of us (which, as I mentioned earlier on the list, only moved to 1.4 when the 1.5 release forced us to), this may be a bit of a problem. Shai. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django 1.6 release timeline
On 30 Apr 2013, at 23:38, Shai Berger wrote: > I see one issue with this: According to current procedures, if this timeline > is followed, support for 1.4 will be dropped less than 6 months after the > release of 1.5. At least for some of us (which, as I mentioned earlier on the > list, only moved to 1.4 when the 1.5 release forced us to), this may be a bit > of a problem. > > Shai. It seems like 1.4 support might need to be extended. I'm assuming that given the success of the kickstarter campaign, Andrew's schema migration functionality will be made available to 1.4, and the functionality seems to be a prerequisite for migrating to the new way of handling user models. Andy -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django 1.6 release timeline
On Apr 30, 2013, at 7:10 PM, Andrew Ingram wrote: > On 30 Apr 2013, at 23:38, Shai Berger wrote: >> I see one issue with this: According to current procedures, if this timeline >> is followed, support for 1.4 will be dropped less than 6 months after the >> release of 1.5. At least for some of us (which, as I mentioned earlier on >> the >> list, only moved to 1.4 when the 1.5 release forced us to), this may be a >> bit >> of a problem. >> >> Shai. > > It seems like 1.4 support might need to be extended. I'm assuming that given > the success of the kickstarter campaign, Andrew's schema migration > functionality will be made available to 1.4, and the functionality seems to > be a prerequisite for migrating to the new way of handling user models. > > Andy There is no requirement to migrate for the new way to handle user models. The only time you'd need to migrate is if you want to swap out your existing user models that Django provides with new ones. If you don't do that then you don't need to migrate. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Django 1.6 release timeline
On 1 May 2013, at 00:13, Donald Stufft wrote: > > On Apr 30, 2013, at 7:10 PM, Andrew Ingram wrote: > >> On 30 Apr 2013, at 23:38, Shai Berger wrote: >>> I see one issue with this: According to current procedures, if this >>> timeline >>> is followed, support for 1.4 will be dropped less than 6 months after the >>> release of 1.5. At least for some of us (which, as I mentioned earlier on >>> the >>> list, only moved to 1.4 when the 1.5 release forced us to), this may be a >>> bit >>> of a problem. >>> >>> Shai. >> >> It seems like 1.4 support might need to be extended. I'm assuming that given >> the success of the kickstarter campaign, Andrew's schema migration >> functionality will be made available to 1.4, and the functionality seems to >> be a prerequisite for migrating to the new way of handling user models. >> >> Andy > > There is no requirement to migrate for the new way to handle user models. The > only time you'd need to migrate is if you want to swap out your existing user > models that Django provides with new ones. If you don't do that then you > don't need to migrate. Absolutely, there's no requirement to migrate, but it does have the feel of an weird kind of deprecation. Obviously there are workarounds, like you said, I can upgrade to 1.5 without changing user models (though that does involve incurring a bit of technical debt). Anyway, this whole line of reasoning was based on the faulty belief that Andrew's work will be added to 1.4, rather than as an external tool, so never mind! Andy -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django 1.6 release timeline
On 04/30/2013 05:27 PM, Andrew Ingram wrote: > Absolutely, there's no requirement to migrate, but it does have the > feel of an weird kind of deprecation. Obviously there are > workarounds, like you said, I can upgrade to 1.5 without changing > user models (though that does involve incurring a bit of technical > debt). I think it's worth being extra-clear about this to avoid scaring people off of 1.5 upgrades with FUD: there is no deprecation of the built-in User model in 1.5, and I doubt that there will be in any upcoming Django version. Neither is there any technical debt incurred by upgrading to 1.5 without switching to a custom User model. Custom user models are a 100% optional feature; continuing to use the built-in User model in 1.5 is not a "workaround" for anything, it's fully supported and reasonable. If you already have working 1.4 code with the existing User model there's little reason you'd want to switch over when upgrading to 1.5 (unless you are also adding new User-related features to your codebase). Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django 1.6 release timeline
Hi Shai, On 04/30/2013 04:38 PM, Shai Berger wrote: > On Tuesday 30 April 2013, Jacob Kaplan-Moss wrote: >> Hi folks - >> >> Unless there are strong objections, here's what I'm thinking for the >> Django 1.6 release timeline: >> >> Alpha: May 16 >> Beta: June 20 >> RC: Aug 1 >> Final: as early as Aug 8, or later if more RCs are needed. >> > I see one issue with this: According to current procedures, if this timeline > is followed, support for 1.4 will be dropped less than 6 months after the > release of 1.5. At least for some of us (which, as I mentioned earlier on the > list, only moved to 1.4 when the 1.5 release forced us to), this may be a bit > of a problem. Yes, thanks for bringing this up. The core team discussed this at PyCon and I believe we had general agreement that if we achieve faster releases we'll need to extend support longer, at least for certain "long-term support" releases (a category which would probably be retroactively applied to 1.4). We haven't hammered out the details of the new policy yet, but I think it's safe to say that if we do release 1.6 on the proposed schedule, we won't drop support for 1.4 at that time. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django 1.6 release timeline
On 1 May 2013, at 00:35, Carl Meyer wrote: > On 04/30/2013 05:27 PM, Andrew Ingram wrote: >> Absolutely, there's no requirement to migrate, but it does have the >> feel of an weird kind of deprecation. Obviously there are >> workarounds, like you said, I can upgrade to 1.5 without changing >> user models (though that does involve incurring a bit of technical >> debt). > > I think it's worth being extra-clear about this to avoid scaring people > off of 1.5 upgrades with FUD: there is no deprecation of the built-in > User model in 1.5, and I doubt that there will be in any upcoming Django > version. Neither is there any technical debt incurred by upgrading to > 1.5 without switching to a custom User model. Custom user models are a > 100% optional feature; continuing to use the built-in User model in 1.5 > is not a "workaround" for anything, it's fully supported and reasonable. > If you already have working 1.4 code with the existing User model > there's little reason you'd want to switch over when upgrading to 1.5 > (unless you are also adding new User-related features to your codebase). > > Carl Don't worry, I'm not misunderstanding you. Andy (Pointless aside: My use of technical debt comes from the idea that pre-1.5 I had a lot of technical debt from hacking user models that couldn't be repaid, so in essence it was written off. Then 1.5 suddenly made it possible to repay it. In general, whenever a new preferred idiom comes along, I consider legacy code to have gained technical debt.) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: design decisions for django-mssql: (switching on autocommit and remote proxy) advice wanted.
On Tue, Apr 30, 2013 at 9:45 PM, VernonCole wrote: > Dear knowledgeable persons: > > I have completed a beta-test version of a Linux remote access server for > adodbapi, and have started the process if integrating them into > django-mssql. (This is going to be an interesting experience for me -- I > have already identified two or three new features that adodbapi needs to > have.) I would like to get your collective wisdom about how to best > accomplish two things. > > 1) The transaction logic will change drastically for django 1.6. For the > supported backends it makes good sense to simply change that in the > repository. However, it is reasonable to expect significant code change > with the upgrade of this backend, and I think that we should maintain a > single code base for a while. I was thinking of behavior similar to what I > do inside of adodbapi: > > ...if sys.version_info >= (3,0): # note that the "if" is executed at > import time, not run time. > ..maxint = sys.maxsize > ...else: > ..maxint = sys.maxint > > Is there something more appropriate than django.VERSION to use for this, > or is it, perhaps, just a bad idea? > If the changes are relatively simple (or easily isolated), django.VERSION switching should work fine. As for whether this is a bad idea - It depends how hard it is to maintain the two side by side. If this will be constrained to a handful of branch points, in well isolated pieces of code, then it will be fairly easy to manage, and in the long term, deprecate the dead code branches. However, if the consequences of auto commit handling are spread throughout the codebase, and require lots of intricate changes, it may end up being a headache. The other approach would be to make versions hard matched -- i.e., django-mssql A.X works with Django 1.5, django-mssql A.Y works with Django 1.6. That way the code only ever has to support one Django version at a time, but the user will need to pay closer attention to which version of django-mssql they actually have deployed. If you want to be really friendly, you could make *this* a once off django.VERSION check. If you want to go all out, you could even mirror Django's versioning, so if you want to use Django 1.6, you need to use django-mssql 1.6 as well. However, that means your release schedule is tied to Django's, and could mean you're forced to make releases when you haven't actually made any significant changes to the codebase. Whether this matters is entirely up to you. > 2) In my unit test programs, I detect whether to use the proxy module or > the regular module depending on whether their is a certain key in the > connection arguments. > > .. import adodbapi > ...import adodbapi.remote > > ...if "proxy_host' in connection_keywords: > ..db = adodbapi.remote > ...else: > ..db = adodbapi > ...db_connection = db.connect(connection_keywords) > > Would there be any technical or political reasons NOT to do that in > sqlserver_ado/base.py ? > If proxy handling is that closely tied to the ADO interface, I'd say it makes sense to put it as close to the metal as possible. I can't think of any political reason not to; as for technical, it really only matters on how closely related proxy handling is to the core interface -- for example, would there be any use case for someone to want to define their own proxy interface. If there is, then you don't want them to be tightly bound; but if the proxy interface is really just another way to configure the connection, then you might as well embed it. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
