Re: Some thoughts about improving migration squashing

be referencing any model (theoretically). But if we assert that RemoveField doesn't refer to any models referenced to by its field, then our optimizer can take a couple more liberties. Raphael On Friday, February 17, 2017 at 2:15:47 AM UTC+9, Markus Holtermann wrote: > > I'm not sure if it's r

Some thoughts about improving migration squashing

AddField(A.foo), CreateModel(B)]) and got decent results, but I think making the optimization code express these two concepts separately would catch even more of the optimizations I saw that the optimizer didn't. I hope some of this is useful Raphael -- You received this message because

Re: Some thoughts about improving migration squashing

I ended up having some time today, so wrote up a management command for the first suggestion! I called it "optizemigration" >>> ./manage.py optimizemigration appname 0001_squashed # snipped django startup noise Optimized from 9 operations to 4 operations Optimized migration

Re: Some thoughts about improving migration squashing

t;protect" the causal order, not "RemoveField". Raphael -- 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

Re: Some thoughts about improving migration squashing

Markus: Now that I've written a command to optimize a single migration file, I think that it's sufficient for the "squash, edit, optimize" workflow that I was doing before. It's more about offering people to get their squashing done well until our optimizer becomes omniscient. Florian: Having

Re: Request to reconsider ticket #27910: using an Enum class in model Field choices

I saw this thread so wanted to share a bit of a gotcha we had with enums internally for anyone trying to handle this stuff Internally, we have a wrapper around CharField to work with enums (we go further than just choices and actually have the values be enums), but there's unfortunately still

Re: Allowing multiple {% block %}s in one template

On 08/06/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > > On 6/8/07, Noam <[EMAIL PROTECTED]> wrote: > > Let me improve my suggestion, so that it mostly solves James' concern > > and can be explained in one sentence: > > > > - > > Multiple blocks with the same name would be allowed, as

Re: Allowing multiple {% block %}s in one template

> Aside from the "urgh!" factor from writing the content in multiple > times, if you are going to do this, why not just create a "reuse-block" > tag that re-inserts the block value the template parser has already > worked out previously? Doesn't need any change to the behaviour of > "block" then.

Re: Allowing multiple {% block %}s in one template

Ok, I've implemented my suggestion. For those concerned about the complexity of implementation, it turns out that all that's needed is a simple change in the block parser, to make it return the same object for all blocks with the same name in a template. The rendering code wasn't touched at all.

Re: Allowing multiple {% block %}s in one template

Ok, I posted my patch at http://code.djangoproject.com/ticket/4529 On 10/06/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > By the way, one advantage of writing the functionality you want as an > extra tag (something not called "block") is that you (or anybody else > who wants to work this

Re: Unicode field names

Thanks a lot - I switched to the unicode branch and it works very nice! I'll report any bugs I encounter. Noam On 13/06/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-06-12 at 21:16 +, Noam wrote: > > Hello, > > > > First of all, I apologize if I post this in the wrong

Re: auto_now_add overwrites a given date

Thanks! Ok, I see that the problem is more complicated than I thought, so I'll leave it that way. I just want to add that if you decide that you don't like the current behaviour, you can always use FutureWarning, to first warn if a value was set and is about to be discarded, and then change the

Re: Problem migrating from South to Django migrations for Linux distributions

Hi Andrew, thanks for your quick answer. On Thu, 24 Jul 2014, Andrew Godwin wrote: > There is no way around this; it's unfortunate that the packaging situation > means that Django will get auto-upgraded as part of a distribution upgrade; > I'm surprised that Debian hasn't had this with packages

Re: Problem migrating from South to Django migrations for Linux distributions

Hi Brian, On Fri, 25 Jul 2014, Brian May wrote: > I can't help but think this might be unrealistic (?). Changes required for > new versions of Django often break compatibility with old versions, and > 1.4.5 is really old now. Just because many packages don't have versioned > dependencies on

Re: Storage engine aliases?

idea? Too much effort for little > gain? Too late? No, I can tell this IS a big source of confusion not only for beginners, so it is worth a change to me. Cheers, Raphael signature.asc Description: PGP signature

Re: ANN: Django website redesign launched

Tino de Bruijn <tin...@gmail.com>: > Does anybody agree on that and should I create a pull request? Absolutely, sounds good! Cheers, Raphael [1] https://github.com/django/djangoproject.com/issues/216 [2] https://github.com/django/djangoproject.com/issues/198 -- You received this messag

Re: Django documentation doesn't show correctly in any browser

obviously is an issue with the Fira Mono webfont, so maybe some weird font cache configuration issues. Does this web page work for you? https://mozilla.github.io/Fira/ Best regards, Raphael -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Feature proposal: Conditional block tags

gh from my uneducated guesses of how the blocks work, this might be very hard and not worthy to implement.) Raphael -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group an

Re: Feature proposal: Conditional block tags

worth that effort. Raphael -- 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...@googlegroup

Re: Psycopg2 version support

No, I believe this is not correct. The system package manager might (or in most cases, will) distribute a _compiled_ version of 2.0.14 where you do not need the -dev libraries to execute them, while pip will download _sources_ and compile them for you and therefore needs the -dev libraries. Raphael -

Re: Password validation in Django revisited

similar fashion to the new TEMPLATES setting. I understand why you chose this style and it might really be the best way to do this one thing, but I fear it adds complexity because it behaves differently than all other settings variables and thus makes it harder to remember how Django's setti

Re: Two phase cleaning of models/forms

Thomas' use case (issue due dates that are required for certain issue states) can be solved using clean() without major drawbacks, for your use case (re-usable address fields), I'd go for MultiValueFields[1] -- this logic does not really belong to the form. Raphael [1] https://docs.djangoproject.

Re: Why deprecate the ability to reverse using the Python path?

rather easy and you should be able to do the migration in half an our without any drawbacks. Best regards, Raphael -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group a

Should migrations have their imports sorted?

bonus feature. Cheers, Raphael -- 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-developer

Re: Should migrations have their imports sorted?

or the noise :) Raphael -- 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.

Re: A new setting for custom gettext domains?

, _FILENAMES sounds as if I should pass either a path or at least a full filename, but it is neither of both.) Raphael Am Tue, 28 Jul 2015 11:48:14 -0700 (PDT) schrieb Tim Graham <timogra...@gmail.com>: > Since adding new settings is sometimes controversial, I wanted to ask > for th

Re: Validate domains against IDNA2008 instead of IDNA2003?

makes use of if present but works completely without it. Cheers, Raphael -- 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,

Re: annoyance with Python 3.2 support in Django 1.8

6 and the django admin. Cheers Raphael -- 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+unsub

ORM difficulties

from date fields Anyways I wanted to share this experience so that anyone who has the courage to right new docs/continue evolving things can know of at least one team’s difficulties. Raphael -- You received this message because you are subscribed to the Google Groups "Django devel

Re: 1.8 shipping invalid .py files in the startapp template

Hello, I'm another Debian developer co-maintaining Django in Debian. Le lundi 30 novembre 2015, Florian Apolloner a écrit : > I am not against including it, but depending on how packaging works in > Debian it could be possible to call pycompile with a proper exclusion list > instead. The PR

Re: Channels integration plan, first draft

n confirm that it is currently very conveniently possible to deploy a Django application on a non-root URL using SCRIPT_PATH without modifying the application. It is not really important to me, but I think it would be worth keeping it in, if it is not too much hassle. Cheers Raphael -- You received this message be

Problems with cache.get_or_set behaviour

dd() is documented as returning True or False and I don't think it makes any sense to return True/False from a method that is expected to return a cached value or a default value. I think we need a better behaviour of get_or_set() if add() fails but I'm unsure how it exactly should look like, otherwis

Sqlite 3.12 breaks the Django test suite

[ CCing an upstream developer of SQlite too ] Hello, I did not want to open a ticket as I'm not sure if the problem is in SQLite or in Django but the Django test suite fails really badly with SQLite 3.12.0 that got recently released (and which is already in Debian Unstable). When using the

Re: Sqlite 3.12 breaks the Django test suite

Le jeudi 07 avril 2016, Aymeric Augustin a écrit : > This other ticket about a SQLite segfault may or may not be related: > https://code.djangoproject.com/ticket/24080 Given how old it is, I was tempted to say it's entirely unrelated. But maybe not. I discovered faulthandler thanks to this and

Adding a database-agnostic JSONField into Django

Hello, in almost all projects I work on, I end up using a JSONField. Since I value being able to run with any database, I'm not relying on django.contrib.postgres.fields.JSONField. So I have been using pypi's django-jsonfield maintained by Matthew Schinckel:

Re: Adding a database-agnostic JSONField into Django

Le vendredi 24 juin 2016, Aymeric Augustin a écrit : > On 24 Jun 2016, at 09:01, Raphael Hertzog <raph...@ouaza.com> wrote: > > Why would you want to discourage people? > Well, this seemed to be the latest decision, but I don’t care much myself. AFAIK only Ma

Re: Adding a database-agnostic JSONField into Django

Hi, Le vendredi 24 juin 2016, Shai Berger a écrit : > > Why would you want to discourage people? In the recent thread "Extending > > JSONField serialization", you said yourself that the use-case for a > > JSONField is clearly to store and retrieve data and not to make queries on > > it with smart

Re: Adding a database-agnostic JSONField into Django

Hi, Le jeudi 23 juin 2016, Aymeric Augustin a écrit : > On 23 Jun 2016, at 15:40, Tim Graham wrote: > > Marc said, "I'm happy for JSONField to be made a core field on the > > condition that it's underlying support is more than a text blob on all > > our main databases. It

Re: change commit message format to present tense?

Hi, Le lundi 27 juin 2016, Reinout van Rees a écrit : > > (You must) "add password validation to prevent the usage of..."! > > "It might be better to think of it as...": it is exactly this extra > thinkwork that everyone reading the messages has to do. We write it once and > read it many times:

Re: Some thoughts about improving migration squashing

tions. We could just do that (start generating RemoveField with field info), though it would not allow for older migrations to get optimized. I'd be good with doing either/both. Raphael On Fri, Feb 17, 2017 at 3:09 PM, Gaschignard, Raphael <raph...@makeleaps.com > wrote: > Hi Simon, &

Re: Model translation and meta options

h multiple of them because it would still be very undefined how you get to the translated versions in the different systems, how you store the data into the field, etc. Cheers Raphael -- You received this message because you are subscribed to the Google Groups "Django developers (Contribu

Re: Some thoughts about improving migration squashing

ause there are, after all, arbitrary migrations. But considering that RemoveField will only be reduced with a "moral equivalent" to AddField, I think we can expand this reasoning across everything to say that RemoveField will be sufficiently protected by the AddField operation's location (which wi

Re: DEP pre-proposal for a simpler URLs syntax.

believe this would be a big burden for people used to the old syntax AND newcomers (because of the autoimport that is not helping). Raphael -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To

Suggestion: Context manager for translation.activate

) the activate() method itself should be changed to optionally work as a context manager Cheers Raphael -- 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 receiv

Re: Suggestion: Context manager for translation.activate

Could you just ignore that I've ever sent this mail? Apparently, I wasn't able to finde translation.override in the docs. Sorry for the noise. Raphael Am Tue, 20 Sep 2016 14:11:11 +0200 schrieb Raphael Michel <m...@raphaelmichel.de>: > Hi, > > in my application, I regularly

Re: Should ugettext_lazy return instanceof unicode? Or are reusable apps responsible for calling force_text a lot?

Hello, Am Fri, 21 Oct 2016 13:49:16 -0700 (PDT) schrieb Mike Edmunds : >1. Should the result of ugettext_lazy somehow inherit from > unicode? I believe this would break giant measures of code out there that use "not isinstace(lazystr, unicode)" exectly to detect that it

Guidelines to name python modules of Django applications?

Hello, in Debian we recently had a discussion about the package name we use for Django applications/extensions, it's usually python-django-. But the generic naming policy we have for all Python modules implies that this package would provide a "django_foo" Python module and this is not always the

Re: Guidelines to name python modules of Django applications?

Le mercredi 07 décembre 2016, Aymeric Augustin a écrit : > In my experience: > > - many Django-related packages use a django- prefix in the name of the package > on PyPI And the mismatch between package name and module name means that we have many packages which are not co-installable because

Re: Guidelines to name python modules of Django applications?

Le jeudi 08 décembre 2016, Raphaël Barrois a écrit : > If I understand correctly the input, would the following proposal be an > acceptable middle ground? It would certainly be an improvement from my point of view, yes. Cheers, -- Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer

Re: Why doesn't the framework provide support for translated database content?

n the talk ;) Cheers Raphael [0] https://groups.google.com/d/msg/django-developers/6a5Bwf5KMNA/HBj-S8ypBgAJ [1] https://2017.djangocon.eu/schedule/data-internationalization-in-django/ [2] https://groups.google.com/d/msg/django-developers/6a5Bwf5KMNA/4q7HNXysBgAJ [3] https://speakerdeck.com/rap

Re: Dynamic app loading

have written a IMHO better plugin handler: > https://gitlab.com/nerdocs/medux/MedUX/blob/develop/medux/extensionsystem/__init__.py > … > This way all plugins can just "implement" predefined Interfaces, > supereasy. I like it! It is more framework-agnostic than our approach and

Re: Dynamic app loading

ers Raphael [1] https://github.com/pretix/pretix [2] https://packaging.python.org/specifications/entry-points/ [3] https://github.com/pretix/pretix/blob/master/src/pretix/settings.py#L264 [4] https://github.com/pretix/pretix/blob/master/src/pretix/base/signals.py#L21 [5] https://github.com/pretix/pre

Re: Adding a database-agnostic JSONField into Django

-jsonfallback Best Raphael P.S. Thanks to all organizers and attendees for an amazing conference <3 -- 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 receivin

Re: Adding a database-agnostic JSONField into Django

type/ > Yes, this is the main difference, as MySQL requires CAST(x AS JSON) calls in many places while MariaDB does not support CAST(x AS JSON). I also noted a number of oddities with regards to case-(in)sensitivity when comparing values extracted from JSON, but I didn't research this deeper

Re: Adding a bulk_save method to models

Hi, I'd be very careful about calling it bulk_save(), since calling it something with save() very strongly suggests that it calls pre_save or post_save signals. Best Raphael Am Fri, 14 Sep 2018 07:56:38 -0700 (PDT) schrieb Tim Graham : > > > I wanted to ask about naming of the n

Faster Migrations! But at what cost?

nce improvements? I am still trying to wrap my head around some of this problem space, so any insight will be very appreciated Thanks, Raphael -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.

Re: Faster Migrations! But at what cost?

a couple ideas now that I'm pretty tempted to try out, mainly around the "fast path and slow path" strategies that should offer backwards compatibility.  Raphael Markus Holtermann wrote on 2019/05/21 2:26: Thanks Raphael for bringing this topic up and Simon for your input already. I ju

Re: GSoC Proposal: Add Cross-DB JSONField, ArrayField, and HStoreField

, this could be done much more nicely. Still, it might be an interesting thing to look at when doing this, if only for the test cases and the weird MySQL/MariaDB things. I'd love to see this in core and are happy to help wherever I can with my expertise. Best Raphael Am Tue, 2 Apr 2019 04:41:36 -0700

Proposal for a transaction.on_before_commit

ping entire database backends) so it would need to be an acceptable change to Django to be a viable option. Thanks Raphael -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group

Re: Proposal for a transaction.on_before_commit

l with all of these separately. Best Raphael Am Sun, 10 Oct 2021 21:38:13 +0200 schrieb Aymeric Augustin : > Hello Raphael, > > Oh - a use case for django-transaction-signals > <https://github.com/aaugustin/django-transaction-signals> ;-) I'm > bringing up this elaborate

Re: Proposal for a transaction.on_before_commit

er around it and because it might become very verbose adding context managers everywhere. Best Raphael -- 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 e

Re: Potential way forward for DATABASE_URL

, December 21, 2022 at 12:06:44 AM UTC+9 Raphael G wrote: > OK after looking at this some more and trying to write up a review aid, > I'm giving up on this branch and trying to integrate DATABASE_URL support > into Django proper. > > A couple reasons: > > - I misread the ori

Re: Potential way forward for DATABASE_URL

the years of usage by everyone as "proof" that the thing works. And I think the branch I tried reviving is "correct", I just don't have the background in most of these backends to know if it's right. On Tuesday, November 29, 2022 at 5:41:41 PM UTC+9 Raphael G wrote: >

Re: Potential way forward for DATABASE_URL

t;I will not need to install an extra package to handle this, nor am I personally parsing the URL with urllib.parse", and am ready to do the legwork. Speaking to that, if we have consensus on the principle, what would be the right step forward? An actual DEP? Raphael On Tuesday, November 29, 2

Re: Potential way forward for DATABASE_URL

! But of course the specifics are important here, so I will finish up a review aid and paste that in the PR (along with actually getting that branch passing) discussion and crosslink it here. On Tuesday, November 29, 2022 at 4:45:12 PM UTC+9 carlton...@gmail.com wrote: > Hey Raphael. > > My o

Potential way forward for DATABASE_URL

Some base industry background. It's a pretty common convention to share credentials in environment variables. For many PaaS, it's common to use connection URLs to do so. So DATABASE_URL will have a URL like postgres://my_user:mypassword@somedomain/database stuffed into a single environment

Re: Integrate dj-database-url into Django

bit off about it, so let's try and get that use case handled in a way that doesn't prevent further niceness in the future! Raphael On Monday, December 24, 2018 at 7:01:23 AM UTC+9 Raffaele Salmaso wrote: > Hi all, > I'm working on https://github.com/django/django/pull/10786 (which is a

Re: Summer of Code 2011: students wanted!

Next steps > -- > > If you've read all that -- and congratulations, by the way! -- the next > things > to do are: > >- Start looking for a project, and draw up some rough plans. > >- Get an initial proposal together, and post it to django-developers. >

Re: Benevolent Dicta^H^H^H Designer for Life

t > http://groups.google.com/group/django-developers?hl=en. > > -- Atenciosamente Raphael Passini Diniz -- 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.c

Re: Sprints DjangoCon Europe

uot; 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. >

Is using version 2 of the pickle protocol in {DB,FileBased}Cache

f.assertEqual(cached_cookie['key'].value, + test_cookie['key'].value) + def test_unicode(self): # Unicode values can be cached stuff = { [1] http://bugs.python.org/issue826897 -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi -

Re: Is using version 2 of the pickle protocol in {DB,FileBased}Cache

ing along the lines of "Set-Cookie: foo=bar; other-parameters;", so validation failed later. Some investigation led me to find the problem in the cache backend I was using, as the cookies inside the cached HttpResponse were being serialized incorrectly and later picked by FetchFromCacheMidd

Re: Is using version 2 of the pickle protocol in {DB,FileBased}Cache

; pickle.HIGHEST_PROTOCOL is also unwanted due to the serialized string being much larger? In case I work on a patch to improve the unit tests for this part, should I file a new ticket? Should this mail have actually been sent as a comment to the ticket? :) -- Raphael Kubo da Costa ProFUSION embed