virtual fields and the migration framework

hat is probably stored in another concrete field Thank you for your attention. Best regards Federico Capoano -- 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 rec

Re: virtual fields and the migration framework

Note that this is just a shot in the dark. I didn't try it out myself. > > /Markus > > On Tuesday, April 21, 2015 at 7:53:04 PM UTC+2, Federico Capoano wrote: >> >> Hi everyone, >> >> some time ago I submitted this ticket: >> https://code.djangoproject.com/t

Re: Idea/request for help: Django Developers Community Survey

Great idea. The questions look good enough to me. I love django-apps or libraries shipped in python packages. One of the reason I love Django is the fact that it didn't frenetically add stuff to the framework just because it's cool. The good thing of python packages is that you can get some

Re: virtual fields and the migration framework

Wednesday, April 22, 2015 at 9:54:39 AM UTC+2, Federico Capoano wrote: > > Hi Markus, > > thank you very much for your suggestion. I'll try it later this afternoon > and come back to report. > > Federico > -- You received this message because you are subscribed to the

Re: virtual fields and the migration framework

I think the correct syntax is: cls._meta.add_virtual_field(self) The problem is that if I use this syntax it seems that the admin ignores these fields, what happens is that the changes I make to the virtual fields are ignored. These are the test results related to the VirtualField

Re: virtual fields and the migration framework

Yes I am on 1.7 because 1.8 is not supported yet but I'm working on it. I'll come back when I'll have more info. Federico On Thursday, April 23, 2015 at 8:09:42 PM UTC+2, Florian Apolloner wrote: > > > > On Thursday, April 23, 2015 at 6:59:58 PM UTC+2, Federico Capoano wrot

Re: Feature: Support Server-Sent Events

Hey Emil, On Sunday, May 31, 2015 at 10:52:26 AM UTC+2, Emil Stenström wrote: ... > Also, I don't think you would need to mix redis (or any other persistent > storage) into this. The connected clients could simply be stored in an > in-memory array, that is discarded if the server crashes.

Re: django.channels: "async" for Django

Hi Andrew, i have been taking a look at your work because I find it interesting and I also think that django should have some core mechanism for integrating websockets. I was wondering, have you also tried one of the other popular django websocket apps? Have you found any interesting one that

Re: virtual fields and the migration framework

not the only one who would like to have flexible/dynamic models :-) Federico On Saturday, April 25, 2015 at 11:48:25 AM UTC+2, Federico Capoano wrote: > > Yes I am on 1.7 because 1.8 is not supported yet but I'm working on it. > > I'll come back when I'll have more info.

Support for UNLOGGED tables in PostgreSQL

I just ran into this ticket: https://code.djangoproject.com/ticket/24306 I found myself in a situation where it would be really useful. Two questions: - has anybody verified that UNLOGGED tables really perform faster when running tests with Postgres? - is this feature on the TODO list

Re: Support for UNLOGGED tables in PostgreSQL

. The best thing would be to have a subsection called "How to speed up tests with Postgres" or something similar. What do you think? Federico On Monday, July 13, 2015 at 5:54:08 PM UTC+2, Aymeric Augustin wrote: > > Hello Federico, > > 2015-07-13 16:26 GMT+02:00 Fede

Re: Proposal: deprecate and remove egg template loader

+1 I am assuming the deprecation is done according to the process that was discussed in the thread "An easier path to upgrade from one LTS release to another". On Sunday, July 12, 2015 at 4:53:23 PM UTC+2, James Bennett wrote: > > There's not much to this, really, except what's in the subject

Re: Support for UNLOGGED tables in PostgreSQL

/docs/current/static/non-durability.html And then some text with "if you want to run your tests on postgresql please see the docs around non durable postgres" 2015-07-13 18:46 GMT+02:00 Federico Capoano <federico.capo...@gmail.com>: > Sure, i've just done something similar for thi

Re: Support for UNLOGGED tables in PostgreSQL

That's quite baffling. On Tuesday, July 14, 2015 at 7:03:03 PM UTC+2, Tim Graham wrote: > > I see a thirty second increase in the test suite (from 7.5 minutes to 8 > minutes) on my local machine with: > > sql_create_table = "CREATE UNLOGGED TABLE %(table)s (%(definition)s)" > -- You received

Re: Renaming the postgresql_psycopg2 backend

I would definitely second this. On Wednesday, July 15, 2015 at 3:17:30 PM UTC+2, Baptiste Mispelon wrote: > > Hi everyone, > > After starting a new project recently and failing three times to type > the name of the postgres backend correctly, I was wondering if there's > really any value in

Re: Support for UNLOGGED tables in PostgreSQL

Hey Christophe, On Thu, Jul 16, 2015 at 8:34 AM, Christophe Pettus wrote: [CUT] > > By the way, I would strongly advise *against* *ever* even mentioning fsync = > off anywhere in the Django documentation; that is such a horribly bad idea in > 99.95% of real-life situations

Re: Support for UNLOGGED tables in PostgreSQL

;> development. They are just as likely to find similar instructions on the >>>> internet, but without warnings, and having it in our docs with the warning >>>> will be helpful. >>>> >>>> Having a fast test suite is such an important part of

Re: Support for UNLOGGED tables in PostgreSQL

Errata, PR link is https://github.com/django/django/pull/5021 - sorry On Mon, Jul 20, 2015 at 11:42 AM, Federico Capoano <federico.capo...@gmail.com> wrote: > Thank you for all the feedback. > > I opened this PR with the proposed addition to the docs: > https://github.com/dja

Re: Support for UNLOGGED tables in PostgreSQL

I just changed the URL in the to http://www.postgresql.org/docs/current/static/non-durability.html as suggested. Federico -- 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

Validation of m2m

Hi everybody, I am sure it has happened to many of you. Validating m2m BEFORE saving the relationships is very hard and time consuming. Now this solution: http://schinckel.net/2012/02/06/pre-validating-many-to-many-fields./ Proposes to solve it with a ModelForm in the admin. Cool, that works.

Re: Validation of m2m

ns, please post your code and ask for help on > django-users. > > -- > Aymeric > > 2015-12-03 13:28 GMT+01:00 Federico Capoano <federico...@gmail.com > >: > >> Hi everybody, >> >> I am sure it has happened to many of you. >> >> Validating

Re: Validation of m2m

ticket about adding model level validation for > many-to-many: https://code.djangoproject.com/ticket/12938 > > On Thursday, December 3, 2015 at 11:04:22 AM UTC-5, Federico Capoano wrote: >> >> Thanks Aymeric, >> >> I decided to post this problem on django-devel

Re: Links from django docs to djangopackages.com should be 'officially endorsed' or not?

It seems like a good proposal, It would be good to know why Sergei doesn't think it is appropiate for Django to add links to third party package comparison grids. django-rest-framework links to third party extensions in its documentation and this had a positive effect on the whole DRF

[admin] submit_row template tag reusability issue

Hi all, I came across the need of modifying the submit row functionality in the django admin and I found out a small issue which prevents me from modifying the template without rewriting (duplicating) also the templatetag entirely. If you take a look at the code of submit_row templatetag

Re: [admin] submit_row template tag reusability issue

jangoproject.com/ticket/13875 > > Feel free to update and/or improve the patch, add tests, and send a pull > request. Thanks! > > > On Monday, February 1, 2016 at 6:18:35 AM UTC-5, Federico Capoano wrote: >> >> Hi all, >> >> I came across the need of modifying the

Re: [admin] submit_row template tag reusability issue

provement in that sense but that shouldn't be difficult. The main blocker > to getting it merged looks like "Needs tests." > > On Tuesday, February 2, 2016 at 10:58:40 AM UTC-5, Federico Capoano wrote: >> >> Hi Tim, >> >> thank you for letting me know of the open

Re: Fellow Report - February 6, 2016

Great work! On Saturday, February 6, 2016 at 4:27:42 PM UTC+1, Tim Graham wrote: > > Triaged > > --- > > https://code.djangoproject.com/ticket/26162 - Data loss when > ManyToManyField refers to the wrong table (accepted) > > https://code.djangoproject.com/ticket/26168 - BooleanField is

Surprising behaviour in case of exception in form widget when DEBUG=False

This never happened to me and I find it very strange. Maybe it's a bug or maybe it's the intended behaviour, but I find it REALLY strange. Consider a widget which, for some reason, raises an exception: class CoolWidget(AdminTextareaWidget): def render(self, name, value, attrs={}):

Re: Surprising behaviour in case of exception in form widget when DEBUG=False

k it's {% include %} rendering an empty string if there's an > exception. In Django 1.9, we added a logger for these exceptions to make > debugging easier: > https://docs.djangoproject.com/en/stable/topics/logging/#django-template. > > On Friday, March 11, 2016 at 6:30:35 AM UTC-5, F

Re: A New Design for the "Congratulations!" Page

That's a great news, let us know if we can help with more feedback. Federico On Fri, Apr 21, 2017 at 9:20 AM Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 18 Apr 2017, at 20:31, Tim Allen wrote: > > Your point on design by committee is spot-on;

A New Design for the "Congratulations!" Page

Looks like a great improvement for newcomers! I hope to see this included to Django. Federico -- 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

Admin raw_id_fields should trigger javascript change event

Hi everyone, I have a raw_id_field in the admin and I need to trigger some javascript logic when it's value is filled by the user through the popup, but unfortunately I found out that when the popup is closed and the value is filled into the field the change event is not fired. I found this

Testing admin inlines painful to debug ("ManagementForm data is missing or has been tampered with")

While writing tests for the admin, I'm clashing with this error message: "ManagementForm data is missing or has been tampered with". It's not the first time I do this, but every time the process has been extremely painful because the error message doesn't point out the exact problem. This time

Re: revisiting the Python version support policy

I would ask: what are the pros and cons of dropping support for python 3.5? I think allowing users to easily use and install django based applications is more important than strictly follow a python version support policy. I think that if we drop support for python 3.5, which is the default

Re: Widening participation (Thoughts from DjangoCon)

Hi everyone, It's been great to read some good insights on this discussion. How to attract new contributors from a different demographic (geographic area and age)? Good question. I wanted to share with you my experience as (second year) organization administrator and mentor for OpenWISP

Re: App label with dot

o.apps.AppConfig.label > > On Friday, December 18, 2020 at 10:47:45 AM UTC-5 Federico Capoano wrote: > >> Defining the app_label of an AppConfig with a dot, like >> "myproject.subapp" is allowed, but raises an exception in the migration >> fram

Re: App label with dot

ere! User-facing > runtime exceptions like unpacking errors are never good. > > This should be quite a simple change to make, I’d suggest opening a trac > ticket first and we can go from there. > > Tom > > On 18 Dec 2020, at 16:38, Federico Capoano > wrote: > >  >

App label with dot

Defining the app_label of an AppConfig with a dot, like "myproject.subapp" is allowed, but raises an exception in the migration framework (too many values to unpack). Did anybody notice this? Is it supposed to be allowed or not at all? Best regards Federico Capoano -- Yo

SynchronousOnlyOperation: bug or misconfiguration?

I have a celery task which performs queries and network operations. When deployed with celery with gevent concurrency, I occasionally (but not always) get reports of SynchronousOnlyOperation exceptions being raised. I described the problem in detail on StackOverflow: SynchronousOnlyOperation

Default change password UX: area for improvements

o raise this here so we may fix it at the root instead. Best regards Federico Capoano -- 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 fro

Re: Set a reasonable default for EMAIL_TIMEOUT

:27 PM UTC-3 Federico Capoano wrote: > Hi there, > > yes I can add EMAIL_TIMEOUT in my applications and I am already doing that. > > The reason I wanted to bring this up here is that I care about Django. > This behavior goes against a well known concept of the Unix Philosoph

Set a reasonable default for EMAIL_TIMEOUT

of spending hours to debug it like I did in the past week. Alternatively, we could set a default timeout only if "socket.getdefaulttimeout()" returns None, just to avoid applications stalling indefinitely, which is something that has been happening to me lately. Best regards Federico Capoan

Re: Set a reasonable default for EMAIL_TIMEOUT

Hi there, yes I can add EMAIL_TIMEOUT in my applications and I am already doing that. The reason I wanted to bring this up here is that I care about Django. This behavior goes against a well known concept of the Unix Philosophy which is to "Write programs which fail in a way that is easy to