Re: Timezone-aware storage of DateTime
Django actually already adds support for some capabilities to certain database backends, if I'm not mistaken - such as cascades through GFKs on delete. In terms of time zones, could django "assume"/ensure that the datetime stored in the backend is UTC, then handle the conversion to the local timezone itself? On Jun 1, 9:16 am, VernonCole wrote: > On May 31, 7:23 am, Daniel Swarbrick > wrote:> I can almost hear the collective sigh as this topic once again rears > > up ;-) > > Thanks for bringing it up. I lurk both here and on db-sig, and intend > to use your well done research to once again attempt an update of the > db-api PEP, which also does not address time zone aware time. I like > the idea of standardizing a cross-platform TZ aware data column. > [...] > > > The way I see it, there are a few options for storage of timestamps in > > SQLite (whose docs clearly acknowledge that it does not officially > > support a timestamp column type). > > > 1. Store timestamps as a Unix epoch value (integer). This is fast, and > > will ensure correct date sorting. On the other hand, it's not really > > human-friendly if manually browsing table data in SQLite. > > Not only is the epoch limited in range, I would be wary of using any > storage based on the python time module (as opposed to datetime). We > have discovered enough subtle bugs in the Windows and IronPython > implementations that we gave up trying to get an accurate test of the > python time option on adodbapi. Things that worked correctly for me in > North America would fail for Mark Hammond in Australia. It is a maze > of twisty little passages. We simply recommend that everyone use > datetime. > > On the other hand, I found it necessary to convert date-time values to > ISO format strings in order to feed them to Microsoft ACCESS databases > in some cases, and that works well. But again, as with SQLite, the DB > has no concept of time zones. In the absence of actual time zone > support in the database, any action taken by django is going to > inconvenience somebody, and will likely not be compatible with non- > django use of the same database. Perhaps it would work to store the > pickled tz-aware datetime on brain-damaged databases. But, is it > reasonable to use an application-specific method to extend the > capability of a database engine? > -- > Vernon Cole -- 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: list_display does not allow foreign keys __ syntax
On Thu, Jun 2, 2011 at 8:58 AM, Luke Plant wrote: > On 25/05/11 10:55, Anshuman Aggarwal wrote: >> Hate to bump a thread, but any thoughts on the last proposal, Luke? > > My personal opinion is that the feature you proposed is not going to be > correct enough of the time to warrant the duplication of code that it > would require to work. > > Other core devs may have a different opinion, I don't know. I concur with Luke's analysis. There is a good reason why double underscore notation isn't appropriate for list_display, and there is already an elegant way to handle the problem. We don't gain anything by providing a second approach that will only work some of the time, crammed into an obscurely named inline function call. 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: list_display does not allow foreign keys __ syntax
On 25/05/11 10:55, Anshuman Aggarwal wrote: > Hate to bump a thread, but any thoughts on the last proposal, Luke? My personal opinion is that the feature you proposed is not going to be correct enough of the time to warrant the duplication of code that it would require to work. Other core devs may have a different opinion, I don't know. Luke -- "Trouble: Luck can't last a lifetime, unless you die young." (despair.com) Luke Plant || http://lukeplant.me.uk/ -- 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: Freelance Python/Django Developers Required
Please do not crosspost to both django-users and django-developers. This message was off-topic for django-developers. -- 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.
Freelance Python/Django Developers Required
Hi Everyone, I am looking for freelance Python/Django developers for a USA based company to work from home. Please contact at farhan_ahme...@odesk.com or fa_mali...@yahoo.com for more information. Thanks, Farhan http://pk.linkedin.com/pub/farhan-malik/34/361/221 -- 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: RFC #9200 -- Refactored form wizard
On 01.06.2011, at 01:37, Luke Plant wrote: > On 30/05/11 10:15, Jannis Leidel wrote: >> Hi all, >> >> Stephan and me are now happy with the latest patch for ticket #9200 >> which refactors the form wizard in the formtools contrib app to >> use class based views and the new secure cookies as one of the >> supported storage backends (a session backend being the other). >> >> https://code.djangoproject.com/attachment/ticket/9200/ticket9200-2.diff >> >> I plan to commit this patch this week so please speak up now if >> you find any problems with the API or docs. >> >> Thanks, >> Jannis >> >> PS: The code can also be found here: >> https://github.com/jezdez/django/tree/feature/formwizard >> > > A few points I noticed, without having done a real review of the working > code: > > * we need something in release notes and deprecation timeline about the > deprecation of the old FormWizard. And presumably some noise about the > new feature in the release notes Indeed, definitely had planned that, done that in the newly attached patch https://code.djangoproject.com/attachment/ticket/9200/9200-3.diff > * if you are adding a warning filter for the old FormWizard in > django/contrib/formtools/tests/__init__.py, I'm guessing there should be > one in tests/regressiontests/formwizard/tests.py as well. Or, you could > perhaps nuke the latter tests - I believe there is large overlap, and I > think one set was added without knowledge of the other. Good catch, I've just merged both test suites since the one in regressiontests does actually test for a specific problem. Jannis -- 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: Timezone-aware storage of DateTime
On May 31, 7:23 am, Daniel Swarbrick wrote: > I can almost hear the collective sigh as this topic once again rears > up ;-) > Thanks for bringing it up. I lurk both here and on db-sig, and intend to use your well done research to once again attempt an update of the db-api PEP, which also does not address time zone aware time. I like the idea of standardizing a cross-platform TZ aware data column. [...] > The way I see it, there are a few options for storage of timestamps in > SQLite (whose docs clearly acknowledge that it does not officially > support a timestamp column type). > > 1. Store timestamps as a Unix epoch value (integer). This is fast, and > will ensure correct date sorting. On the other hand, it's not really > human-friendly if manually browsing table data in SQLite. Not only is the epoch limited in range, I would be wary of using any storage based on the python time module (as opposed to datetime). We have discovered enough subtle bugs in the Windows and IronPython implementations that we gave up trying to get an accurate test of the python time option on adodbapi. Things that worked correctly for me in North America would fail for Mark Hammond in Australia. It is a maze of twisty little passages. We simply recommend that everyone use datetime. On the other hand, I found it necessary to convert date-time values to ISO format strings in order to feed them to Microsoft ACCESS databases in some cases, and that works well. But again, as with SQLite, the DB has no concept of time zones. In the absence of actual time zone support in the database, any action taken by django is going to inconvenience somebody, and will likely not be compatible with non- django use of the same database. Perhaps it would work to store the pickled tz-aware datetime on brain-damaged databases. But, is it reasonable to use an application-specific method to extend the capability of a database engine? -- Vernon Cole -- 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: Preventing the leaking of sensitive information in error logs
On 29/05/11 05:22, Julien Phalip wrote: > Recently I've been a bit embarrassed to receive a 500-error email > report containing a client of mine's password displayed in clear > because the admin login view had encountered an unhandled exception. > This is probably OK in a debug environment but in production this can > potentially have damaging consequences when handling passwords, credit > card numbers, etc. It may also go against certain policies and > standards such as the PCI-DSS (http://en.wikipedia.org/wiki/ > Payment_Card_Industry_Data_Security_Standard). > > There is already an open ticket to address this issue: > https://code.djangoproject.com/ticket/14614 > > I first wrote a patch allowing a lot of granularity to control which > POST/GET parameters should get obfuscated when producing the error > logs: > https://code.djangoproject.com/attachment/ticket/14614/14614.obfuscate-request-parameters.diff > > Russell pointed out that this implementation approach was overly > complicated. It also doesn't address the stack frame variables being > logged in some situations. So I've posted another patch with a more > radical approach, where all stack frame variables and the request's > information are systematically and entirely omitted from the logs for > exceptions occurring in views marked with the @sensitive decorator: > https://code.djangoproject.com/attachment/ticket/14614/14614.sensitive-request.diff I think we probably do need to provide something here. I'm concerned that a 'sensitive' decorator puts the decision in the hands of the app writer, which may well not be appropriate. For example, in one case I'm involved in, half of the data entered in the admin in sensitive to some degree, but my ability to debug errors could be seriously hindered if the whole thing had 'sensitive' slapped on it. (Thankfully, the data isn't too critical, and it is enough that I just delete the error e-mails once I've dealt with them). So, the 'sensitive' decorator might be appropriate for login, and possible some other views, but I'm concerned it is still going to leave other important situations with no practical solution. Would it possible to make the sensitive decorator add some kind of strategy object to the request, which itself is responsible for the filtering, rather than a simple boolean flag? The strategy object interface might be: class ExceptionReporterFilter(object): def show_request(self, request): # return True or False def filter_request_POST(self, request, post_dict): # if show_request is True, this is passed request.POST # and returns a sanitised version def show_traceback(self, request): # True or false def show_traceback_vars(self, request): # called only if show_traceback() returns True def filter_traceback_vars(self, request, tb_frame, vars): # filters vars to be shown at each level. OK, could get carried away there - maybe we should start simple, e.g. just 'show_request' and 'show_traceback_vars'. But something like that would allow us to provide a working 'sensitive' decorator, but with a mechanism that allows for something more fine-grained, and allows us to add more features to it easily in the future. For the admin and CBVs it would work as well, since there are always places you can override a method and attach something to the request object. If I'm thinking correctly, with an additional method like 'filter_settings', it might be possible to have a default ExceptionReporterFilter that does the filtering of settings that is currently hardcoded into django/views/debug.py. Regards, Luke -- "The truth will set your teeth free." (Calvin and Hobbes) Luke Plant || http://lukeplant.me.uk/ -- 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.
