Re: Replacing the contrib.sites Site model with a setting?
This is just that I'm doing in django-sites package:
https://github.com/niwinz/django-sites .
+ to have the similar approach in django (sites as settings).
On Fri, Jan 29, 2016 at 10:45 PM, Tim Graham <timogra...@gmail.com> wrote:
> In another thread about adding a "scheme" field to the Site model [1], I
> floated the idea of moving the data stored by the Site model into a setting:
>
> I've sometimes thought that the Site model violates the principle that you
> shouldn't put configuration in your database. I guess there's some
> usefulness to having a ForeignKey to the site, but... would it be feasible
> to offer a SITES setting that could be used instead? e.g.
>
> SITES = {
> 1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
> ...
> }
>
> Carl said:+1 to this, I've long felt that the Site model was an
> anti-pattern. I don't know if it's worth deprecating and switching to a
> different system, though; it'd be a relatively painful deprecation for
> those using it, I would guess.
>
> James said: "In using Marten Kenbeek's URL dispatch rewrite branch, I've
> found that using the pattern of defining some site configuration in your
> settings is the way to go: it more easily allows you to have URL patterns
> on multiple domain/scheme combinations. I use a dict similar to what Tim
> has shown, and then use it to initialize my scheme/domain URL constraints
> in my root urls.py."
>
> I'd like to get more feedback and ideas about this. Do you think we'll be
> better off in the long run with a setting as opposed to storing the data in
> the database? Maybe writing a new sites app that uses a setting instead of
> trying to modify the existing models-based one would be a better plan.
>
> I think the hard problem to solve is what to do about the Redirect and
> FlatPage models which have ForeignKey and ManyToManyField relations to the
> Site model.
>
> Perhaps some outcome of this discussion plus considering what features of
> related third-party tools like django-hosts [2] might be useful to
> incorporate in Django itself would be worthy of a project like Google
> Summer of Code.
>
> [1]
> https://groups.google.com/d/topic/django-developers/CzxaPDe8fpI/discussion
> [2] https://github.com/jazzband/django-hosts
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/52fee0b1-c08f-4ac5-a01e-34b9baa045ec%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/52fee0b1-c08f-4ac5-a01e-34b9baa045ec%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
Andrey Antukh - Андрей Антух - <n...@niwi.nz>
http://www.niwi.nz
https://github.com/niwinz
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAOQnsABkw3Ba-i4nC3rxoXqELv4d8ZNhp3h27NtF_KE4xWkvdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Vote on Jira as bugtracker
Hi Joe On Fri, Jan 8, 2016 at 7:16 AM, Joe Tennies <tenn...@gmail.com> wrote: > I'm not a lawyer, but I care about licensing. > > The MIT License would allow you to relicense it, but you must keep the > original copyrights in tact. (From license: Redistribution and use in > source and binary forms, *with or without modification*, are > permitted...) > > It does have a list of "buts" too. > > You must keep the copyright and disclaimer in the source files you used, > and your documentation must also do that. > > Typical answer is to add a header above it in the source and then state > that all modifications from the original are AGPL... Original code is: > leave theirs alone. > > You typically add "Portions of the code are based on Django Rest Framework > which is *paste copyright and lack of warranty etc disclaimer*" > to your documentation. > On each file imported from DRF we have a notice about the original copyright: # This code is partially taken from django-rest-framework: # Copyright (c) 2011-2014, Tom Christie But as you are suggesting, the best approach would be paste the entire original license preamble. We will do it ASAP. Thank you very much. Regards. Andrey > > On Thu, Jan 7, 2016 at 7:12 PM, Carl Meyer <c...@meyerloewen.net> wrote: > >> Hi Andrey, >> >> On 01/07/2016 04:23 PM, Andrey Antukh wrote: >> > On Fri, Jan 8, 2016 at 12:42 AM, Florian Apolloner >> > The DRFv2 (as DRFv3) as far as I know is licensed using MIT permissive >> > license that does not impide take the source and re-license it under >> > other license. >> > >> > taiga.io <http://taiga.io> initially have started using the DRF just >> > like a dependency but over time the dev-team found the needs monky-patch >> > many and many parts of it... Later, the dev-team have decided just >> > include it in the code base and remove useless (for taiga) code and add >> > additional features. >> > >> > Much of code/improvements is contributed back to the DRF (v2), other as >> > third party packages and some other is no, because the approaches are >> > diverged and the changes are just to much opinionated/coupled to the >> > taiga usage. >> > >> > I hope I have solved your question. >> >> I am not a lawyer, but it seems to me the problem is not the use of the >> code (which the license does allow), but the re-licensing and the lack >> of the original DRF license in your codebase. >> >> You are allowed to use the code and re-distribute it, but AFAIK you are >> not allowed to re-license it unless you are the copyright owner. And the >> terms of the DRF license do require that the DRF license text be >> preserved along with any redistribution of the DRF code, which (as far >> as I can see) Taiga currently doesn't do. >> >> So if I'm right (which I may well not be), I think the issue is easily >> resolved by including the original DRF license text in your base/api/ >> directory, and clarifying that that license (not the AGPL) is the >> license that applies to all code taken from DRF. >> >> Carl >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/568F0D05.3050901%40meyerloewen.net >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Joe Tennies > tenn...@gmail.com > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CACiOJ6sFEP%3D-i3z8ge3JDXm7%3Dn0xDgg3bOE%2BjHJDJruuvz8ONw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CACiOJ6sFEP%3D-i3z8ge3JDXm7%3Dn0xDgg3bOE%2BjHJDJruuvz8ONw%40mail.gmail.com?utm_medium=email_source=footer
Re: Vote on Jira as bugtracker
HI Florian On Fri, Jan 8, 2016 at 12:42 AM, Florian Apolloner <f.apollo...@gmail.com> wrote: > Hi Yamila, > > On Thursday, January 7, 2016 at 2:22:21 PM UTC+1, Yamila Moreno wrote: >> >> I just wanted to let you know that me or anyone in our team would be glad >> to answer any question about the product, saas or installation, migrating >> issues or anything related. No strings attached, of course!!! >> > > I personally do actually have one question. I was looking through your > source code and realized that you are apparently importing DRF and changing > a few parts and relicensing it as AGPL. I am not a lawyer and you might > actually be allowed to do that, but what about contributing to DRF back > instead? Your AGPL code (again I am not a lawyer and might be wrong), > actually forbids Tom to take your changes back into DRF… That said, the DRF > license requires you to retain the copyright information, either I missed > it or you did not retain it. > The DRFv2 (as DRFv3) as far as I know is licensed using MIT permissive license that does not impide take the source and re-license it under other license. taiga.io initially have started using the DRF just like a dependency but over time the dev-team found the needs monky-patch many and many parts of it... Later, the dev-team have decided just include it in the code base and remove useless (for taiga) code and add additional features. Much of code/improvements is contributed back to the DRF (v2), other as third party packages and some other is no, because the approaches are diverged and the changes are just to much opinionated/coupled to the taiga usage. I hope I have solved your question. Regards. Andrey > > Do not get me wrong, but if half what I wrote is true; I'd personally be > very worried if Django switched to Taiga, given the signal that this would > send to our userbase (might be just me though). > > Cheers, > Florian > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/4f189a3c-9011-4b06-994f-ec4b1a346c9c%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/4f189a3c-9011-4b06-994f-ec4b1a346c9c%40googlegroups.com?utm_medium=email_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Andrey Antukh - Андрей Антух - <n...@niwi.nz> http://www.niwi.nz https://github.com/niwinz -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAOQnsABOv9-o8h1Cstv4UU4SEFpebaiQoJf3ADA9PdX1QaiQsQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: uuid field short websafe representation
Hi.
2014-12-08 10:41 GMT+01:00 Radek Svarz <radek.sv...@gmail.com>:
> Michael, Florian, I understand your remarks.
>
> Allow me to explain more.
>
> I do not advocate to replace the code by the one posted by me. I rather
> advocate to improve it.
>
> ad 1) I just react to the current implementation, where in the case of
> other DBMS than PostgreSQL the hex value in 32 chars is stored. In such
> cases I propose to store it in a smaller amount of 21 characters. ( =
> storage optimization )
>
As far as I know, postgresql internally stores it in binary format.
>
> ad 2) web safe representation
> The goal is to translate URLs back and forth. E.g.
> server.com/apiv1/client/uuid/0b043d5842ca4cab9750b705018f4a1f should
> allow direct mapping to the ORM object. I am not sure whether the current
> implementation allows that. Or at least the documentation is not clear
> about it.
>
> ad >> A non-standard, compressed unique value is not a UUID.
> Base64 is just different encoding, so value wise you still get the same
> UUID.
>
In my opinon, -1.
The presentation format of uuid should not affect in any way the storage of
it. Currently with backends that supports nativelly uuid types as
postgresql, stores it in the most efficient way.
My two cents!
Regards.
Andrey
> Radek
>
> On Sunday, December 7, 2014 10:16:00 AM UTC+1, Florian Apolloner wrote:
>>
>> +1 to everything you said, if someone wants a "websafe" representation,
>> they can always just manually call safe_uuid on the UUID instance.
>>
>> On Saturday, December 6, 2014 6:00:58 PM UTC+1, Michael Manfre wrote:
>>>
>>> A non-standard, compressed unique value is not a UUID. Also, this forces
>>> database backends to store the value in a string datatype and doesn't allow
>>> taking advantage of uuid specific datatypes. E.g. Postgresql couldn't use
>>> its uuid datatype. Any data can be made safe for any specific usage, e.g.
>>> URLs, but there is no reason to enforce this requirement in all uses of the
>>> data because not everyone will expose a UUID in a URL.
>>>
>>> -1 from me.
>>>
>>> Regards,
>>> Michael Manfre
>>>
>>> On Sat, Dec 6, 2014 at 11:31 AM, Radek Svarz <radek...@gmail.com> wrote:
>>>
>>>> Hi, I am glad to see the UUID field coming to 1.8
>>>>
>>>> Bellow is how we do it now in 1.7.
>>>>
>>>> The advantages:
>>>>
>>>> - it only uses 21 chars (instead of 32)
>>>>
>>>> - chars are safe for URLs
>>>>
>>>> - uuid is created when default is called
>>>>
>>>> I advocate to have the short websafe representation. What do you think?
>>>>
>>>> code:
>>>>
>>>>> def safe_uuid():
>>>>> return uuid.uuid4().bytes.encode('base64').rstrip('=\n').replace('/',
>>>>> '_')
>>>>>
>>>>
>>>>
>>>>> class UUIDField(CharField) :
>>>>> """
>>>>> UUIDField stored in 21 Chars
>>>>> Example: uuid = UUIDField(primary_key=True, editable=False)
>>>>> """
>>>>> description = "UUIDField stored in 21 Chars"
>>>>> def __init__(self, *args, **kwargs):
>>>>> kwargs['max_length'] = kwargs.get('max_length', 22 )
>>>>> kwargs['default'] = safe_uuid
>>>>> CharField.__init__(self, *args, **kwargs)
>>>>>
>>>>> def deconstruct(self):
>>>>> name, path, args, kwargs = super(UUIDField, self).deconstruct()
>>>>> return name, path, args, kwargs
>>>>
>>>>
>>>> Radek
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Django developers (Contributions to Django itself)" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to django-develop...@googlegroups.com.
>>>> To post to this group, send email to django-d...@googlegroups.com.
>>>> Visit this group at http://groups.google.com/group/django-developers.
>>>> To view this discussion on the web visit https://groups.google.com/d/
>>>> msgid/django-developers/1c29dfae-6483-465c-939e-
>>>> f4319120781f%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/django-developers/1c29dfae-6483-465c-939e-f4319120781f
Re: [ANNOUNCE] Django 1.7 released
Awesome! Thanks! 2014-09-03 0:15 GMT+02:00 Carlos Aguilar <darkange...@gmail.com>: > congratulations!!! > > And thank you for a really good job! > > Best Regards > > > On Tue, Sep 2, 2014 at 4:13 PM, James Bennett <ubernost...@gmail.com> > wrote: > >> Django 1.7 is now available: >> >> https://www.djangoproject.com/weblog/2014/sep/02/release-17-final/ >> >> Alongside this are bugfix releases for 1.4, 1.5 and 1.6. The bugfix 1.5 >> release is the final releae in the 1.5 series, as Django 1.5 has now >> reached end-of-life. >> >> -- >> 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. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAL13Cg_Cdzf3aYLxfV0qgrMY3CqbOqt%3D0DxEm1V27%2BzF65O_cA%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CAL13Cg_Cdzf3aYLxfV0qgrMY3CqbOqt%3D0DxEm1V27%2BzF65O_cA%40mail.gmail.com?utm_medium=email_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Carlos Aguilar > Consultor Hardware y Software > DWD > http://www.dwdandsolutions.com > http://www.houseofsysadmin.com > Cel: +50378735118 > USA: (301) 337-8541 > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAN-g%3Dg%3DW_9MXJiFawGX%2BczkVXLRKhdb6Zvp3AQU6sjnf2zPy7g%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAN-g%3Dg%3DW_9MXJiFawGX%2BczkVXLRKhdb6Zvp3AQU6sjnf2zPy7g%40mail.gmail.com?utm_medium=email_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Andrey Antukh - Андрей Антух - <andrei.anto...@kaleidos.net> / <n...@niwi.be > http://www.niwi.be <http://www.niwi.be/page/about/> https://github.com/niwibe -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKn%3DmOMrosWn7EOiyQJMD4%2Bph6jO681dT%3DKb-S-4MT5p2sBeAA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Data Migrations and Testing
2014-04-19 14:15 GMT+02:00 Anssi Kääriäinen <anssi.kaariai...@thl.fi>: > On 04/19/2014 10:52 AM, Anssi Kääriäinen wrote: > > Getting dump-and-reload support for 1.7 seems hard, so from the above >> options this leaves just 2) - not deprecating initial_data yet. Or we >> need to find some other solution not listed above. >> > Hmmh, there is actually a pretty straightforward upgrade path for this > case. Just rename your initial_data fixtures to something else, and add > them as normal testing fixtures in your TestCases. Of course, this requires > some work to do, but it is a viable upgrade path. > > It is clear that migrations can't be used as a replacement for > initial_data when testing, so we need some improvements to the release > notes in any case. > Completely agree with you. +1 > > > - 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. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-developers/535268EF.3010903%40thl.fi. > > For more options, visit https://groups.google.com/d/optout. > -- Andrey Antukh - Андрей Антух - <andrei.anto...@kaleidos.net> / <n...@niwi.be > http://www.niwi.be <http://www.niwi.be/page/about/> https://github.com/niwibe -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKn%3DmOOE34RsCMprPCLfCT0o8KUArNoXGKXrDRapbNNSg4u%2BkA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Data Migrations and Testing
Hi Marc. Thanks for you explanation. 2014-04-19 13:46 GMT+02:00 Marc Tamlyn <marc.tam...@gmail.com>: > Hi Andrey, > > There are limited use cases where initial data is a good idea. Examples > might be where you have a list of countries for relating to or some other > fixed set of data. > > The idea is that now instead if having a hard to maintain fixture for that > table, you populate it with a data migration instead. This means if I for > example add a new column to that table, you get a migration to add the > column then one to populate it (then one to make it not null) as opposed to > just the one migration which you then run, manually back around the > database to get it populated, update the fixture dump, deploy and then > reload that (potentially overwriting old data). > I understand that use of intial_data is not he best approach and +1 for deprecate/remove it, but put migrations as replacement (or suggest it on docs) is really confusing. My purpose for this, is removing the suggestion on release notes to use migrations as replacement of initial_data, because migrations just as word says is for data migrations not inital data. Personally I think the new version is much better. That said, there are > limited use cases for this feature. > The current version is much better because removes features with bad usage practices. But as I previously said, do not suggest an other bad approach as replacement. > Marc > On 19 Apr 2014 12:21, "Andrey Antukh" <n...@niwi.be> wrote: > >> Hi Christian. >> >> But, as far as I know, data migrations are "some logic" for translate >> data from old scheme to new scheme and initial_data are files for load >> intial data. I do not see where they could serve for the same purpose. Is >> really confusing. >> >> Personally, putting initial data of my application mixed with migration >> logic is bad approach for me. But is my opinion. :D >> >> Greetings. >> Andrey >> >> >> >> >> >> 2014-04-19 13:13 GMT+02:00 Christian Schmitt <c.schm...@briefdomain.de>: >> >>> hm, at first i didn't even read the release notes.. >>> But i think we should definitly make a blocker issue in trac. >>> Currently re-introduce initial_data is the worst thing we could do, >>> since django 1.9 requires migrations and do deprecate that behavior: >>> > Deprecated since version 1.7: If an application uses migrations, >>> there is no automatic loading of fixtures. Since migrations will be >>> required for applications in Django 1.9, this behavior is >>> > considered deprecated. If you want to load initial data for an app, >>> consider doing it in a migration. >>> >>> Currently I think that the third solution could be the best, in my case >>> we have like a dataset of 50 or more entries as initial data, which could >>> easily be mocked and/or dumped and reloaded. It won't take that much time. >>> And as you already said for bigger applications fixtures didn't work, too. >>> But I don't think it will make it in Django 1.7 and since data >>> migrations are unusable if you rely on testing and initial_data this >>> wouldn't be too good. >>> >>> > At this time I haven't touched the new migrations system for django. >>> But now, reading the releases notes and this thread... >>> > I don't understand how data migrations can replace initial_data, are >>> two things completely different and they have completely different scope. >>> I'm slightly confusing. >>> >>> Data Migrations are the same thing than initial_data i mean they can be >>> used to load a data set and drop that dataset, thats way more flexible. But >>> currently Django's TestSuite isn't prepared for Data Migrations. Thats >>> infact a problem. >>> >>> -- >>> 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. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/6c14d75b-6720-4c97-b697-93adb759f134%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/6c14d75b-6720-4c97-b697-93adb759f134%40googlegroups.com?utm_medium=email_source=footer> >>> . >>> >>>
Re: Data Migrations and Testing
Hi Christian. But, as far as I know, data migrations are "some logic" for translate data from old scheme to new scheme and initial_data are files for load intial data. I do not see where they could serve for the same purpose. Is really confusing. Personally, putting initial data of my application mixed with migration logic is bad approach for me. But is my opinion. :D Greetings. Andrey 2014-04-19 13:13 GMT+02:00 Christian Schmitt <c.schm...@briefdomain.de>: > hm, at first i didn't even read the release notes.. > But i think we should definitly make a blocker issue in trac. > Currently re-introduce initial_data is the worst thing we could do, since > django 1.9 requires migrations and do deprecate that behavior: > > Deprecated since version 1.7: If an application uses migrations, there > is no automatic loading of fixtures. Since migrations will be required for > applications in Django 1.9, this behavior is > > considered deprecated. If you want to load initial data for an app, > consider doing it in a migration. > > Currently I think that the third solution could be the best, in my case we > have like a dataset of 50 or more entries as initial data, which could > easily be mocked and/or dumped and reloaded. It won't take that much time. > And as you already said for bigger applications fixtures didn't work, too. > But I don't think it will make it in Django 1.7 and since data migrations > are unusable if you rely on testing and initial_data this wouldn't be too > good. > > > At this time I haven't touched the new migrations system for django. But > now, reading the releases notes and this thread... > > I don't understand how data migrations can replace initial_data, are two > things completely different and they have completely different scope. I'm > slightly confusing. > > Data Migrations are the same thing than initial_data i mean they can be > used to load a data set and drop that dataset, thats way more flexible. But > currently Django's TestSuite isn't prepared for Data Migrations. Thats > infact a problem. > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/6c14d75b-6720-4c97-b697-93adb759f134%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/6c14d75b-6720-4c97-b697-93adb759f134%40googlegroups.com?utm_medium=email_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Andrey Antukh - Андрей Антух - <andrei.anto...@kaleidos.net> / <n...@niwi.be > http://www.niwi.be <http://www.niwi.be/page/about/> https://github.com/niwibe -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKn%3DmOP9_PoEZTmmm7PF7c-2_ikmkSXHk151m_iEYhB%2Broivwg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Data Migrations and Testing
Hi! At this time I haven't touched the new migrations system for django. But now, reading the releases notes and this thread... I don't understand how data migrations can replace initial_data, are two things completely different and they have completely different scope. I'm slightly confusing. In any case, great work. Thanks Andrey 2014-04-19 9:52 GMT+02:00 Anssi Kääriäinen <anssi.kaariai...@thl.fi>: > On 04/18/2014 07:41 PM, Andrew Godwin wrote: > >> Ah yes, flushing, I forgot we did that for lesser DBs. >> >> I can think of several solutions: >> - Run the entire migration set every time you flush the database. This >> is, obviously, not practicable. >> - Re-introduce initial_data fixtures; I'd rather not, as these require >> constant upkeep and interact badly with migrations. >> - Dump the content of all apps at the start of tests into a file and >> restore from that after flushes. This is a bit hacky and might use a lot of >> disk space, but would get the intended effect. >> - Say that you can't use datamigrations if you have a database without >> transactions (not ideal) >> >> Nothing here is really a great solution, alas. The fourth one is the >> easiest solution - tell people to use factories in tests or fixtures if >> they want that stuff - but slightly undermines the idea of loading initial >> data in a migration (which is the better way of doing it). >> >> Perhaps we should look into deprecating flushing? It's not a behaviour >> that can be easily replicated any more, as it relied on the old system of >> one-shot schema and load a single file, but it's also kind of crucial to >> non-transactional tests... >> > > Unfortunately deprecating flushing isn't possible. For each test in > TransactionTestCase Django flushes the database. So, this problem hits > everybody using initial_data and TransactionTestCase independent of > transaction support of the database used. > > As for why things break for normal TestCase, too - after creating the > database and running all the migrations Django flushes the database - so > all migration data is flushed, too. > > Of the above choices that leaves only the first three, and of those the > first is already ruled out. > > Option 3) might actually work pretty well. Dump all data for managed > tables just after migrations have ran, then load it back after each flush. > If the data amounts are too large to make this practical, then they surely > were impractical for initial_data or fixtures, too. In addition we could > use faster forms of data loading (COPY for PostgreSQL, similar > optimizations exists for other databases, too). > > Even if one isn't using any initial data in their project, Django does it > with contenttypes and permissions. We already optimized this for Django's > test suite, and this resulted in more than halving the runtime of the suite > (granted, Django's test suite has more models than normal projects). > > Getting dump-and-reload support for 1.7 seems hard, so from the above > options this leaves just 2) - not deprecating initial_data yet. Or we need > to find some other solution not listed above. > > - 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. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-developers/53522B3C.3050901%40thl.fi. > > For more options, visit https://groups.google.com/d/optout. > -- Andrey Antukh - Андрей Антух - <andrei.anto...@kaleidos.net> / <n...@niwi.be > http://www.niwi.be <http://www.niwi.be/page/about/> https://github.com/niwibe -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKn%3DmOMtrLNBZ%2BNfjz6GCpg-8sKQQ7iEKBhP40fOsCR_KtWfyQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [GSoC] Switching to Jinja2 proposal
Hi Aymeric
2014-02-10 21:56 GMT+01:00 Aymeric Augustin <
aymeric.augus...@polytechnique.org>:
> On 10 févr. 2014, at 20:16, Carl Meyer <c...@oddbird.net> wrote:
>
> > I've proposed it before, and not in jest. Though perhaps not fully
> > seriously either, as full seriousness would mean supplying a patch.
>
> I've heard an ex-BDFL accepting the idea. The other ex-BDFL was there and
> he
> didn't throw the first one through the window. Hence, the idea is accepted
> ;-)
>
> I would do it if I had the time.
>
> (As a full-time employee and father, my time isn't exchangeable for money.)
>
> The MVP would look like this:
>
> 1) Design a convention to tell DTL templates apart from Jinja2 templates.
> My
> favorite option is {# syntax: django #} or {# syntax: jinja2 #} in the
> first
> line of the file. Using a file extension would work too. For files that do
> not
> follow the convention, Django would default to DTL for two releases and
> then
> to Jinja2. Let the bikeshed begin ;-)
>
> 2) Convert all built-in templates Jinja2. Provide suitable replacements for
> template filters and tags we care about. This is a great opportunity to
> remove
> some historical cruft like the add filter.
>
> 3) Update various bits of template-related infrastructure appropriately.
> Given
> than jingo has less than 500 LoC excluding tests, and that Django's
> Template
> abstraction is very straightforward, I'm cautiously optimistic.
>
> This is a great opportunity to improve the pluggability of the template
> engine.
> If we do a good job, it will be possible to turn the legacy DTL into a
> separate
> project. We may have to make it less stateful to get there, maybe building
> on
> Christopher Medrela's patches (#17093).
>
> I have only one significant concern. Jinja2 is still a one-man-project [1]
> and
> that man has taken a public stance on Python 3 that is at odds with
> Django's.
> It's often misinterpreted as "Python 3 sucks" after a cursory reading.
>
> That said, I'm pretty sure that Jinja2 is more robust that the DTL, even
> under
> Python 3. I'm only worried about the PR. Whether we like it or not,
> software
> needs PR. I don't want to have to answer ridiculous comments such as "Look,
> Django is migrating to a template language anchored in Python's past!"
>
I agree with you in all most all your points, with exception to this point.
Jinja2 as far as I know, is one of the first template engine that had
python3 suport. I think
these type of comments should not exists.
As you have said previously, jinja2 is a one man project, but if django
adopts it, probably
it get a boost.
Andrey
>
> [1] https://github.com/mitsuhiko/jinja2/graphs/contributors
>
> --
> Aymeric.
>
>
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/70B2B842-9977-4F60-B743-4662019DE56A%40polytechnique.org
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
Andrey Antukh - Андрей Антух - <andrei.anto...@kaleidos.net> / <n...@niwi.be
>
http://www.niwi.be <http://www.niwi.be/page/about/>
https://github.com/niwibe
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAKn%3DmOOtyTruo3jSSOYf%2B6tQtMMOv-6fpASjTqpvVZgwHLjpUw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Feature request: post/pre commit/rollback signals
Hi! 2014/1/18 Aymeric Augustin <aymeric.augus...@polytechnique.org> > On 18 janv. 2014, at 19:50, Carl Meyer <c...@oddbird.net> wrote: > > > Those interested in this feature may find django-transaction-hooks [1] > useful. It is my attempt to implement the commonly-useful case (run some > code after the current transaction successfully commits, providing the code > wasn't registered during a savepoint which was later rolled back.) I think > the API provided by django-transaction-hooks is actually better for that > use case than transaction signals are, since it does the work of handling > some situations correctly (savepoints, closed connections), which in the > case of signals are left up to the signal receiver to handle (or more > likely, not bother to handle.) > > > > Testing and feedback welcome. If this becomes widely used and seems to > fill a need, I think there is a chance it could become part of Django core. > (See #21803.) > > I think this is the right approach. I would use that package. I support > adding it to Django. > You are absolutely right! This is much best approach than using signals (I also don't like signals, my approach was only for show a use case). And I think that this is much less intrusive (and without signals), and would be awesome if it be added to django. This use case is very common in web development. > Since it doesn’t do anything until after the transaction has successfully > committed, it cannot interfere with the transaction management code. That’s > my most important requirement and the reason why I’m so strongly opposed to > pre-commit/rollback signals. > > If you look at the first email in this thread, the use case is “do > something when a transaction is committed successfully”. In the later email > that gives an example, it only uses post_commit. Generic transaction > signals look like a collective hallucination to me, or at least a pretty > bad case of YAGNI. > > -- > Aymeric. Thanks! Greetings. Andrey -- Andrey Antukh - Андрей Антух - <andrei.anto...@kaleidos.net> / <n...@niwi.be > http://www.niwi.be <http://www.niwi.be/page/about/> https://github.com/niwibe -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKn%3DmONTxxVA_HMHuMzxabL6zgG83f1NpUQyaoqV13LY5y%3DZ1A%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Feature request: post/pre commit/rollback signals
Thanks for your package and clear explanation ;) Greetings. Andrey. 2014/1/11 Aymeric Augustin <aymeric.augus...@polytechnique.org> > On 11 janv. 2014, at 11:05, Andrey Antukh <n...@niwi.be> wrote: > > > In my opinion, "the default case are solved with atomic block" seems to > be a workaround instead of a solution. > > As a short reminder, we’re talking about inconsistencies that arise when: > > 1) you do something in the database; > 2) you do something related in another system — send an email, enqueue a > task, cache a value; > 3) the database transaction is rolled back, canceling the effects of 1) > but not those of 2). > > I may have been unclear when I closed the ticket. I’m not saying that > atomic blocks solve the problem. I’m saying that the problem doesn’t happen > in autocommit mode, which is the default in Django >= 1.6. > > If you’re using transactions (i.e. ATOMIC_REQUESTS or atomic blocks), you > may encounter the problem. But then I’m positive that transaction signals > aren’t the solution. > > > I understand that signals in general are evil and register global > callbacks is not a very good solution, but I think, that a orm should give > some generic facility to attach code to execute when a transaction is > successfully committed or rolled back. > > I’m not having this argument once more, so, there you go: > https://github.com/aaugustin/django-transaction-signals > https://pypi.python.org/pypi/django-transaction-signals-do-not-use > > You may also be interested in: > https://github.com/davehughes/django-transaction-signals > https://pypi.python.org/pypi/django_transaction_signals > > (The name conflict is unfortunate; I didn’t check before writing my > package; at least that forced me to include a warning in the name.) > > Jokes aside, transaction signals are just a (wrong) means to an > (legitimate) end. I’ve documented the solutions I’m aware of: > https://github.com/aaugustin/django-transaction-signals#alternatives > > Additional ideas welcome! > > -- > Aymeric. > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/989FB6EA-12A2-4D54-9821-FB8473F3AF29%40polytechnique.org > . > For more options, visit https://groups.google.com/groups/opt_out. > -- Andrey Antukh - Андрей Антух - <andrei.anto...@kaleidos.net> / <n...@niwi.be > http://www.niwi.be <http://www.niwi.be/page/about/> https://github.com/niwibe -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKn%3DmONL6KGBtgZR7fwUN7iLEmjhJa0xP23Pdq3MHHaHMcJ%2BTg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Feature request: post/pre commit/rollback signals
Hi! In my opinion, "the default case are solved with atomic block" seems to be a workaround instead of a solution. I understand that signals in general are evil and register global callbacks is not a very good solution, but I think, that a orm should give some generic facility to attach code to execute when a transaction is successfully committed or rolled back. For example, one possible use case can be this: import threading from django.dispatch import receiver from django.core.signals import request_started from .signals import post_commit _local = threading.local() _local.post_commit_tasks = [] @receiver(post_commit, dispatch_uid="_run_defered_tasks") def _run_defered_tasks(sender, **kwargs): while _local.post_commit_tasks: task = _local.post_commit_tasks.pop(0) task[0](*task[1], **task[2]) @receiver(request_started, dispatch_uid="_clean_tasks") def _clean_tasks(sender, **kwargs): _local.post_commit_tasks = [] def delay_until_transaction(func, *args, **kwargs): _local.post_commit_tasks.append((func, args, kwargs)) This is one of much other examples that try to solve this (problem/use case) out of django, and I think that django/django-orm should provide some facility to defer execution some code after a transaction is commited or rolled back. In the last aaugustin comment, he suggest one approach without using global signals, and it seems very interesting approach. Can these approach to be generalized and included in django? As Jesus said, it not seems a isolated problem, and would be awesome if django provides some generic and good way to do this. Greetings. Andrey. 2014/1/10 Andreas Pelme <andr...@pelme.se> > > On 10 jan 2014, at 09:19, Jesús Espino <jespi...@gmail.com> wrote: > > > Hi folks! > > > > The propose is add post and pre signals for commit and rollback actions > (as sqlalchemy orm events). This allows attach some code when a transaction > is committed or rolled back. > > > > I have some problem, such as send email only when a transaction is > committed successfully, and it's can be done with simple monkey patching > the db backend. But it not appear to be an isolated problem, and would be > awesome if these signals are included in core. > > > > If a purpose is accepted, I can take care of making the issue + > pull-request. > > > > Greetings. > > Jesus. > > > Hi, > > This is a tricky issue that has been discussed earlier, you will probably > want to check out ticket #14051: > > https://code.djangoproject.com/ticket/14051 > > — > Andreas Pelme > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/948D5F1E-F86D-44A0-9EEA-F1E9A6A4A382%40pelme.se > . > For more options, visit https://groups.google.com/groups/opt_out. > -- Andrey Antukh - Андрей Антух - <andrei.anto...@kaleidos.net> / <n...@niwi.be > http://www.niwi.be <http://www.niwi.be/page/about/> https://github.com/niwibe -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKn%3DmOOq-dE8Nc9b604DnUkriRp2mhW90nx5nfc9PUuNyHn4dA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Reopen bug #18776 (urlparse do not support reverse_lazy as url arg)
Hi Michal. In my opinion, your usage of reverse_lazy is wrong. You should use reverse as is (not lazy). You should use lazy method when you declare class attributes, etc... Andrey 2013/6/22 Michal Sládek <mic...@sladkovi.eu> > I checked the original fix and made similar changes in > django/http/response.py: > > 6a7 > > from django.utils.encoding import force_str > 457c458,459 > < parsed = urlparse(redirect_to) > --- > > redirect_to_as_str = force_str(redirect_to) > > parsed = urlparse(redirect_to_as_str) > > I don't know whether it is proper solution or not, but as a temporary fix > it works for me. > > > Michal > > -- > 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. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Andrey Antukh - Андрей Антух - <n...@niwi.be> http://www.niwi.be/about.html http://www.kaleidos.net/A5694F/ "Linux is for people who hate Windows, BSD is for people who love UNIX" "Social Engineer -> Because there is no patch for human stupidity" -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proposal: Support for HTTP PATCH method
+1 Many times I had to add this method to the test client. 2013/5/20 Krzysztof Jurewicz <krzysztof.jurew...@gmail.com> > There is a RFC describing HTTP method named PATCH: > > http://tools.ietf.org/html/**rfc5789 <http://tools.ietf.org/html/rfc5789> > > Quoting that RFC: > “ The difference between the PUT and PATCH requests is reflected in the >way the server processes the enclosed entity to modify the resource >identified by the Request-URI. In a PUT request, the enclosed entity >is considered to be a modified version of the resource stored on the >origin server, and the client is requesting that the stored version >be replaced. With PATCH, however, the enclosed entity contains a set >of instructions describing how a resource currently residing on the >origin server should be modified to produce a new version.” > > Django currently has (seemingly shallow) support for PUT method. Based on > that, I’ve grepped for places in code where it is implemented to see if > support for PATCH could be easily added on a basis of symmetry. Those > places are: > > In test client: > There is a `put` method, but `patch` is also implemented: > https://github.com/django/**django/commit/**293f7a21147ad94c92c7d5b3f33cba > **b2f87b001b<https://github.com/django/django/commit/293f7a21147ad94c92c7d5b3f33cbab2f87b001b> > > In View class: > https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d** > 73b9d46476/django/views/**generic/base.py#L33<https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/base.py#L33> > `put` is listed in http_method_names > > In RedirectView: > `put` is a fallback to .get(): > https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d** > 73b9d46476/django/views/**generic/base.py#L207<https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/base.py#L207> > > In ProcessFormView: > https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d** > 73b9d46476/django/views/**generic/edit.py#L164<https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/edit.py#L164> > PUT is implemented as a fallback to POST and it seems to assume that > request data is form encoded. While it is not generally true for PUT > method, it looks like a reasonable assumption when processing a form. > However since PATCH request doesn’t have to contain full form data, I think > the best approach may be to not implement `patch` method here (unless we > want to deal with editing only some of the form’s fields – for example this > is the case in Rails, where PATCH will be the primary method for updates in > 4.0 version: http://weblog.rubyonrails.org/** > 2012/2/25/edge-rails-patch-is-**the-new-primary-http-method-**for-updates/<http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-the-new-primary-http-method-for-updates/>). > The same stays true to `get_form_kwargs` method in FormMixin: > https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d** > 73b9d46476/django/views/**generic/edit.py#L44<https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/edit.py#L44> > In general, Django’s approach to whether PUT should be treated as a > request containing form data seems to be inconsistent because we generate > forms in the views, but we refuse to generate PUT QueryDict on a request > object: https://groups.google.com/d/**msg/django-developers/** > dxI4qVzrBY4/m_9IiNk_p7UJ<https://groups.google.com/d/msg/django-developers/dxI4qVzrBY4/m_9IiNk_p7UJ>. > So maybe it’s worth to consider removing PUT support in form processing > just on the basis of consistency. > > In conclusion, it seems pretty easy to add basic PATCH support similar to > PUT. So if it gets enough +1s, I’m willing to make a patch and hope it gets > included in 1.6 alpha. Or maybe it is (from a technical point of view) so > small a feature that it doesn‘t need to be merged before alpha release? > -- > Krzysiek > > -- > 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+unsubscribe@**googlegroups.com<django-developers%2bunsubscr...@googlegroups.com> > . > To post to this group, send email to > django-developers@**googlegroups.com<django-developers@googlegroups.com> > . > Visit this group at http://groups.google.com/** > group/django-developers?hl=en<http://groups.google.com/group/django-developers?hl=en> > . > For more options, vi
Re: Proposal: ModelForm API improvements
Other possible option is for ideas: http://django-crispy-forms.readthedocs.org/en/latest/index.html ;) 2013/3/7 Loic Bistuer <loic.bist...@sixmedia.com> > +1 > > This logic would be better in `ModelForm`. > > -- > Loic > > On Mar 8, 2013, at 2:42 AM, Bruno Renié <bubu...@gmail.com> wrote: > > My proposal is to move that field customization API from the > ModelAdmin class back to ModelForm: > > > -- > 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. > > > -- Andrey Antukh - Андрей Антух - <n...@niwi.be> http://www.niwi.be/about.html http://www.kaleidos.net/A5694F/ "Linux is for people who hate Windows, BSD is for people who love UNIX" "Social Engineer -> Because there is no patch for human stupidity" -- 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: Switch to database-level autocommit
If not I'am wrong, postgresql uses "read commited" by default and mysql
"repeatable read"
http://www.postgresql.org/docs/9.1/static/transaction-iso.html -> "Read
Committed is the default isolation level in PostgreSQL. "
http://dev.mysql.com/doc/refman/5.0/en/innodb-transaction-model.html -> "In
terms of the SQL:1992 transaction isolation levels, the default InnoDB
level is REPEATABLE READ. InnoDB"
Andrey
2013/3/4 Aymeric Augustin <aymeric.augus...@polytechnique.org>
> On 4 mars 2013, at 04:04, Shai Berger <s...@platonix.com> wrote:
>
> > you need to be sure that, in all these places, either reads don't
> > really affect consequent writes, or some constraint holds that is
> equivalent to
> > serializability -- otherwise, negative effect is possible.
>
> PostgreSQL and Oracle use the "repeatable read" isolation level by
> default. They are
> immune to this problem, because a sequence of reads followed by a write
> has the same
> semantics with a transaction under "read committed" and without a
> transaction.
>
> MySQL uses "read committed" and SQLite uses "serializable". Users of these
> databases
> may see a different behavior.
>
> I'm going to add this to the list of backwards incompatibilities:
>
> https://github.com/aaugustin/django/commit/876fddb68dd6990e87b15e683c498e41f8921f14#L4R437
> ("Using unsupported database features" isn't correct for MySQL and SQLite
> right now.)
>
> Let me know if you think of other cases which I haven't covered!
>
> --
> Aymeric.
>
> --
> 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.
>
>
>
--
Andrey Antukh - Андрей Антух - <n...@niwi.be>
http://www.niwi.be/about.html
http://www.kaleidos.net/A5694F/
"Linux is for people who hate Windows, BSD is for people who love UNIX"
"Social Engineer -> Because there is no patch for human stupidity"
--
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: Database pooling vs. persistent connections
Also, https://github.com/niwibe/djorm-ext-pool is based initially on postgresspool but works with sqlite and mysql. The only difference is that uses monky patching instead a separate backend. We also use it in production on a project a while ago and has not given us any problems. Andrey 2013/2/17 Carl Meyer <c...@oddbird.net> > On 02/17/2013 11:31 AM, Anssi Kääriäinen wrote: > > It seems SQLAlchemy has a mature pooling implementation. So, yet > > another approach is to see if SQLAlchemy's pooling implementation > > could be reused. (Maybe in conjunction with the above 'POOLER' idea). > > There is in fact an implementation of reusing SQLAlchemy's connection > pool with Django (via DatabaseWrapper subclassing): > https://github.com/kennethreitz/django-postgrespool/ > > I have this in production for several months with no issues, so the > concept certainly works. > > Carl > > -- Andrey Antukh - Андрей Антух - <n...@niwi.be> http://www.niwi.be/about.html http://www.kaleidos.net/A5694F/ "Linux is for people who hate Windows, BSD is for people who love UNIX" "Social Engineer -> Because there is no patch for human stupidity" -- 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: Possible memory leak with CBV's ?
Thank you very much for the great explanation. I'll try to avoid using __del__ methods whenever possible. Andrey 2013/1/7 Anssi Kääriäinen <anssi.kaariai...@thl.fi> > Avoid __del__ if possible, -- Andrey Antukh - Андрей Антух - <n...@niwi.be> http://www.niwi.be/about.html http://www.kaleidos.net/A5694F/ "Linux is for people who hate Windows, BSD is for people who love UNIX" "Social Engineer -> Because there is no patch for human stupidity" -- 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.
Possible memory leak with CBV's ?
I've been experimenting, and I found a strange behavior. In the View class if I define the __ del__ method, and is never executed. In instances of other classes, which are members of View, feel the same behavior (eg HttpRequest is not removed by a garbage collector). The fault lies primarily in this line (django/views/generic/base.py): def view(request, *args, **kwargs): # [...] *if hasattr(self, 'get') and not hasattr(self, 'head'): self.head = self.get* # [...] When you create alias methods once the class has been instantiated seems to make some references (cyclical?) which prevent the garbage collector remove them. I have reproduced the same behavior with simple classes to verify the problem: https://gist.github.com/4475138 If a custom view defines a head method, the problem disappears. So, is how it should work? I'm wrong about something? Thank you very much. -- Andrey Antukh - Андрей Антух - <n...@niwi.be> http://www.niwi.be/about.html http://www.kaleidos.net/A5694F/ "Linux is for people who hate Windows, BSD is for people who love UNIX" "Social Engineer -> Because there is no patch for human stupidity" -- 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: 1.5, update_fields and PostgreSQL (or other MVCC style database) - request for documentation note
2012/11/3 Christian Jensen <christ...@jensenbox.com> > I was just writing some code against 1.5 and thought I might use the new > .save(update_fields=['xyz']) then I realized I was using PostgreSQL - which > is an MVCC... which re-writes the entire row as far as I know even when one > column is being updated. > > I popped into the release notes and it does in fact indicate that it is > useful for high concurrency scenarios. > > I thought it would be nice to note in the docs somewhere that it is really > not useful for database of this type unless you are using a healthy amount > of the update_fields elsewhere. > > I might be wrong on all of this. > > I have never made a documentation change nor have any idea what the > process would be so if someone chooses to make this note, please do! > > Thanks everyone! > Christian > Another important point is that you avoid unnecessary data transfer. Many times the database is on another physical server and transfer all the data from a table that has many columns, when you just need to change a few, is more expensive and has more latency. Furthermore, using "only" and "defer", avoiding additional queries are made to the database, the fields for deferred. Just save what you really have on the object. All this regardless of what the database server do internally. Andrey -- Andrey Antukh - Андрей Антух - <n...@niwi.be> http://www.niwi.be/about.html http://www.kaleidos.net/A5694F/ "Linux is for people who hate Windows, BSD is for people who love UNIX" "Social Engineer -> Because there is no patch for human stupidity" -- 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.
