Re: ANN: Django website redesign launched

[Raphael Michel]

Hi,

I agree with Tino in most points.
Thanks to the volunteers who did this and I really love the fact,
that I can finally browse the docs on a mobile device. Great!

But there certainly is a loss of both originality and the readability.
Both of these things are no blockers and don't make the new design
really bad, but both are things worth improving.

For originality, bringing back some of the old colors could help. They
suited Django very well and looked less like a million other pages out
there. I can't really help here, as I am no talented designer.

For readability, I like Tino's suggestion as well as the tickets [1]
and [2]. I think with minor improvements like a modified line height,
more bold headlines and more contrast in boxes and code, this
documentation could be both as modern as the new design and as readable
as the old one :)

Am Wed, 17 Dec 2014 12:58:37 +0100
schrieb Tino de Bruijn :
> 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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20141217162141.215d6d1d%40arlen.
For more options, visit https://groups.google.com/d/optout.


pgpUY8xpnNQF4.pgp
Description: Digitale Signatur von OpenPGP

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

[Raphael Michel]

Am Tue, 13 Jan 2015 20:36:45 +0100
schrieb Aymeric Augustin :
> Well, there are 10k subscribers to this list. Who else is seing this?

I don't, and I run pretty much the same configuration (Chrome on Arch
Linux on multiple computers). I think it pretty 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  (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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150113211107.5439856e%40arlen.
For more options, visit https://groups.google.com/d/optout.


pgpJRQIYJSl_y.pgp
Description: Digitale Signatur von OpenPGP

Re: Feature proposal: Conditional block tags

[Raphael Michel]

Hi,

Am Sat, 31 Jan 2015 18:12:57 +
schrieb Unai Zalakain :
> Correct me if I'm wrong but the same exact behaviour can be achieved
> by:
> 
> {% block myblock %}
> {% if myvariable %}
> my content
> {% else %}
> {{ block.super }}
> {% endif %}
> {% endblock myblock %}

I guess you're right, but that's exactly Markus' point. This is
inconvenient -- it is exactly one of those tradeoffs Aymeric
mentioned, and seems not well balanced to me, as does not look good in
the template code and I don't suppose that every Django developers
knows about {{ block.super }}.

What is the technical reason for {% if … %}{% block %} not being
possible (or, not behaving as expected)? Enabling this syntax would
improve readability a lot and satisfy Markus' request as well
without introducing new syntax.
(Although 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 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/20150131221221.574c4180%40arlen.
For more options, visit https://groups.google.com/d/optout.


pgp0X_QE5nl3g.pgp
Description: Digitale Signatur von OpenPGP

Re: Feature proposal: Conditional block tags

[Raphael Michel]

Hi,

Am Sat, 31 Jan 2015 22:36:05 +0100
schrieb Aymeric Augustin :
> I suspect it has to do with {% if %} being interpreted at runtime
> while {% block %} is interpreted at compile time.
> 
> I never investigated this fully. If someone does, I’m interested :-)

This was my guess as well. However, if this indeed is the reason, then
a {% block … if … %} syntax would make it impossible to interpret
blocks at compile time, and I don't think Markus' proposal (or the {%
if %}{% block %} syntax, which I do like more than {% block if %}) is
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...@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/20150201145722.76fae6d0%40arlen.
For more options, visit https://groups.google.com/d/optout.


pgpE_TMS5x3Re.pgp
Description: Digitale Signatur von OpenPGP

Re: Psycopg2 version support

[Raphael Michel]

Am Mon, 16 Feb 2015 01:15:53 -0800 (PST)
schrieb Thomas Stephenson :
> The postgres-*.*-dev libraries are a requirement for both 2.0.14 and
> 2.5, so if it's possible to install 2.0.14 via the package manager
> then it's possible to pip install 2.5.

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

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150216133103.2c3600e5%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpZgwRpUl_Xd.pgp
Description: Digitale Signatur von OpenPGP

Re: Password validation in Django revisited

[Raphael Michel]

Hi Erik,

Am Sun, 8 Mar 2015 15:47:27 +0100
schrieb Erik Romijn :
> I've taken another stab at 16860[1]: having a password
> validation/policy in Django. I've made an initial simple PR[2] to
> show the approach I'd like to use - no tests or documentation yet,
> the example validators are not very nice, possibly bad naming, etc.
> But this should be sufficient to show how I would like to tackle
> this. There's quite a few decisions to take, influencing the later
> possibilities, which I'll try to outline below.

I really like this a lot, both the idea of the ticket and the way
you're proposing to implement it.

However, I'm not quite sure whether I like the style you chose to pass
constructor arguments in the PASSWORD_VALIDATORS setting you proposed. I
believe it might be worth considering to design the PASSWORD_VALIDATORS
setting in a 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 settings work.

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.
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/20150308172841.3775a4df%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpI3LsGgFZcH.pgp
Description: Digitale Signatur von OpenPGP

Re: Two phase cleaning of models/forms

[Raphael Michel]

Hi,

Am Thu, 2 Apr 2015 09:15:42 -0700 (PDT)
schrieb Preston Timmons :
> One use case is for validating address forms. We deal with a lot of
> them with varying levels of validation based on country, state, zip
> code, etc. Sometimes, multiple sets of address fields appear on the
> same form. We can't simply reuse the fields without worrying about
> disparate validation routines specified on the form in addition to the
> fields. This leads to a meticulous set of mixins. It gets the job
> done, but I don't think that's great api.

While 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.com/en/1.8/ref/forms/fields/#multivaluefield

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150408204959.6e08dc20%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpO3ul2YEB_7.pgp
Description: Digitale Signatur von OpenPGP

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

[Raphael Michel]

Am Thu, 16 Apr 2015 01:21:04 -0700 (PDT)
schrieb guettli :
> We never jumped on the "give the URLs a name" wagon.

Why don't you go with Tim's idea to implement a custom url() method to
automatically give the views their path as URL names? This should be
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 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/20150416103313.79d5f25d%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpBXxZAuLhmG.pgp
Description: Digitale Signatur von OpenPGP

Should migrations have their imports sorted?

[Raphael Michel]

Hello,

some time ago, Django started to use isort to make sure imports are
formatted and sorted consistently throughout the codebase. I like this
very much, so I started adopting this practice for my own codebases.

However, today I noticed that when Django generates a migration, the
imports in the outputted python file are not necessarily sorted,
causing my checks to fail. In my case it was about these imports:

-from django.db import models, migrations
+from django.db import migrations, models

I had a short look at the source code, but being a novice to the
django.db subtree, I had no idea where exactly to look and I wanted to
ask here: Is this something trivial to fix or is it something that
cannot be solved without changing things very deeply?

This is, of course, absolutely not important, if not completely
irrelevant. However, if it would be a really easy fix, it could be a
nice 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-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/20150726005423.74fa6353%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpyStu8Idok4.pgp
Description: Digitale Signatur von OpenPGP

Re: Should migrations have their imports sorted?

[Raphael Michel]

Am Sat, 25 Jul 2015 16:32:21 -0700 (PDT)
schrieb Tim Graham :
> I think it's been addressed in 1.9 to at least some extent. See 
> https://github.com/django/django/commit/7f20041bca43ca33f0a9617793f2af7ab07c3fab

Oh, I didn't find that. Wonderful, sorry for 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.
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/20150726110721.557235cc%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpA742XfliXB.pgp
Description: Digitale Signatur von OpenPGP

Re: A new setting for custom gettext domains?

[Raphael Michel]

Hi,

I think the setting is worth it, it can be really useful when working
with complex translation setups.

However, I feel that LOCALE_FILENAMES is a poor choice for the setting
name, as it differs from standard gettext terminology in a very unclear
way. Why not name it LOCALE_DOMAINS?
(To me, _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 :

> Since adding new settings is sometimes controversial, I wanted to ask
> for thoughts about this ticket [1] / pull request [2] which proposes
> a new LOCALE_FILENAMES setting to allow using additional gettext
> domains besides "django". I don't use translations myself, so
> thoughts about whether the usefulness of the feature justifies a new
> setting or if there is some other solution to the problem described
> in the ticket would be welcome.
> 
> [1] https://code.djangoproject.com/ticket/6376
> [2] https://github.com/django/django/pull/5053
> 

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150820153900.300d77ec%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpyKOcMfnmQ2.pgp
Description: Digitale Signatur von OpenPGP

Re: Validate domains against IDNA2008 instead of IDNA2003?

[Raphael Michel]

Hi,

Am Wed, 2 Sep 2015 14:35:22 -0700 (PDT)
schrieb Tim Graham :
> However, python standard lib [
> https://docs.python.org/3/library/codecs.html?highlight=idna#module-encodings.idna
>  
> only offers IDNA2003] validation in , and one have to use [
> https://pypi.python.org/pypi/idna a 3rd party lib] to encode/validate 
> against IDNA2008. 

If I do not miss something, this is a "bug" in Python and not in Django.

However, I believe it could be good idea to have the 3rd-party idna
package as an optional dependency that Django 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, 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/20150902235105.7718b8d1%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpovt7EcT3MO.pgp
Description: Digitale Signatur von OpenPGP

Re: annoyance with Python 3.2 support in Django 1.8

[Raphael Michel]

Hi,

Am Wed, 25 Nov 2015 16:36:52 -0800 (PST)
schrieb Tim Graham :
> b. Install the latest non-broken Python 3.2 release (3.2.5)
> "manually" (without using deadsnakes) on the newer CI servers

While it would only really hurt the people in charge with the bugfix
releases, as Django 1.8 will be around for another 2.5 years, I think
dropping CI is not a good idea, considering that is comparatively easy
to compile specific python versions by oneself.

However, we should definitely document somewhere that there are
possbile unknown problems with 3.2.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+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/20151126152618.2f4dba63%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpBiht4aGxUy.pgp
Description: Digitale Signatur von OpenPGP

Re: Channels integration plan, first draft

[Raphael Michel]

Hi,

Am Thu, 17 Dec 2015 12:27:07 -0700
> I'll admit to not being an expert on this use case at all, since I
> don't generally do it, but AFAIK SCRIPT_NAME remains pretty key for
> transparently deploying a Django site at non-root URL paths.

I used  this before and can 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 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/20151217203754.4f15a4cf%40arlen.
For more options, visit https://groups.google.com/d/optout.


pgpkpxtq5I83X.pgp
Description: Digitale Signatur von OpenPGP

Re: Storage engine aliases?

[Raphael Michel]

Hi,

Am Thu, 2 Oct 2014 08:46:26 +0200
schrieb Jannis Leidel :
> If something like that were be tried I would also recommend to fix
> the ambiguity with regard to “media” and “static” by renaming the
> first to “uploads”.
> 
> What do others think about that 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

Proposal for a transaction.on_before_commit

[Raphael Michel]

Hi everyone,

I've spent some days thinking about a use case we have internally where
we want to create some database records automatically based on some
other records, think e.g. of an audit log where whenever an instance of
model X is changed, we want to create an instance of model Y as a log
record. Of course, there are *lots* of ways and libraries that allow you
to do this with Django, mostly somehow circling around overriding
`save()` or using the `post_save` signal.

However, we want to do this in an *aggregated* way, i.e. even if you
add hundreds of model instances in the same transaction, we only want
*one* new line in our audit log to be created. This is impossible with
`save()` or `post_save` alone since we can't know which change is the
"last" that should trigger the audit log to be created.

I figured a perfect way to do this would be using `save()` or
`post_save` to add the changed model instance to some kind of
thread-local list, and then using `transaction.on_commit` to "schedule"
the aggregation and create the log entries when all changes have been
made. However, this obviously is not a good enough because `on_commit`
runs *after* the `COMMIT` statement and thus we're not guaranteed that
all log entries are persisted to the database.

So I was wondering if there was potential for a
`transaction.on_before_commit` that works just like
`transaction.on_commit` except that it is executed before the `COMMIT`
statement. I imagine there are lots of other possible uses as well and
without looking into it much deeper, it seems easy enough to implement.

Does anyone have opinions on whether or not this would be a good
feature to add to Django? Unfortunately it doesn't seem possible to do
this as third-party code (except if we were shipping 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 and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20211010155522.6489b86d%40amara.localdomain.


pgpl51uPmIu7I.pgp
Description: Digitale Signatur von OpenPGP

Re: Proposal for a transaction.on_before_commit

[Raphael Michel]

Hi Aymeric,

thank you for the insightful reply. Indeed I have overlooked the issue
with savepoints which makes it much more fragile. In our case, "not
using savepoint rollbacks any more" would be a trade-off that we'd
happily make (there are enough other problems with savepoints to begin
with), but I understand that this kinda disqualifies it for a
first-class feature in Django :(

A middleware is not an option for us, as we intentionally don't use
ATOMIC_REQUESTS and not all code is triggered through requests (celery
tasks, management commands, …) and we'd like to avoid to deal 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
>  ;-) I'm
> bringing up this elaborate joke because you're essentially asking for
> a "pre-commit" signal here and the README contains a good list of
> things that can go wrong with transaction signals. (Please ignore how
> this package demonstrates a way to do it as third-party code *cough*
> *cough* *cough*)
> 
> > I figured a perfect way to do this would be using `save()` or
> > `post_save` to add the changed model instance to some kind of
> > thread-local list, and then using `transaction.on_commit` to
> > "schedule" the aggregation and create the log entries when all
> > changes have been made. However, this obviously is not a good
> > enough because `on_commit` runs *after* the `COMMIT` statement and
> > thus we're not guaranteed that all log entries are persisted to the
> > database.  
> 
> 
> In my opinion "saving the log entries may fail after a successful
> transaction" isn't the main design problem here. The bigger problem
> is "log may contain entries for writes that don't actually happen,
> because some savepoints were rolled back, typically due to atomic
> blocks exiting with an exception". And then you get dragged into the
> whole complexity that the README of django-transaction-signals
> outlines and that we're trying to avoid in Django.
> 
> (If you don't have any savepoint rollbacks, then your code sounds
> sufficiently constrained to implement logging of changes explicitly
> at the application layer rather than at the framework layer.)
> 
> If you run with ATOMIC_REQUESTS, I would suggest to replace it by a
> custom middleware that wraps get_response(request) in an atomic
> block. Then you know that this is the outermost traction and you can
> do whatever needed before exiting the atomic block. You also need the
> same in all management commands, which could be a problem if you
> depend on third-party management commands.
> 
> Failing that, in order to log changes with transactional correctness
> enforced by the ACID guarantees of PostgreSQL, I'd recommend doing it
> at that database level with triggers — which always execute in the
> same transaction. I realize it may be difficult to perform the kind
> of aggregation you have in mind.
> 
> As a last resort, I'd try a custom database backend to track
> accurately transactions and savepoints and maintain an up-to-date
> record of changes that will happen when the transaction is committed.
> 
> Hope this helps!
> 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20211012112820.57a47da3%40kvothe.

Re: Proposal for a transaction.on_before_commit

[Raphael Michel]

Hi,

Am Sun, 10 Oct 2021 18:38:55 +0300
schrieb Shai Berger :
> Why is a before-commit signal preferable to a vanilla Python
> context-manager around the code? Or, if it is in the context of
> requests, a middleware?

basically mostly because you can forget to put the context manager
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 emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20211012112913.26138880%40kvothe.

Re: Dynamic app loading

[Raphael Michel]

Hi Christian,

we are doing such a thing for quite a while in our open source project
pretix[1]. I'm not sure if its something that Django needs to do
better, since requirements for this tend to deviate a lot and there's
already a solid basis in the Python packaging toolchain to start from:
To discover apps/plugins, we rely on setuptools' entry point
feature[2], which allows us to easily load all compatible apps
installed in the local Python requirement.

We then disable/enable plugins on a per-client level by using a custom
subclass from Signal[4] and automatically wrapping all views with a
decorator that makes them conditional[6] through some URLConf inclusion
tricks[5].

>From a plugin author perspective, this makes for a pretty clean view[7]
and we are pretty satisfied with the approach. You can also watch me
explaining it here: https://www.youtube.com/watch?v=5NxRdzLTFik

Cheers
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/pretix/blob/master/src/pretix/multidomain/maindomain_urlconf.py#L23
[6]
https://github.com/pretix/pretix/blob/master/src/pretix/multidomain/plugin_handler.py
[7] https://docs.pretix.eu/en/latest/development/api/index.html

Am Sun, 29 Jul 2018 13:26:04 +0200
schrieb Christian González :

> Hello DjangoDevs,
> 
> I'm new here to this group, and to be honest, just a "fake" developer.
> Doing that is not my main job. So please be patient with my maybe
> BadIdea(tm).
> 
> Another warning: much text. Hint: there is a TL;DR at the end.
> 
> I stumbled upon a "missing feature" in Django, which I call "dynamic"
> app loading, a while ago, since I try to create a Django based
> application which can dynamically add plugins to itself.
> 
> I first tried to google the internet, and found many Stackexchange Q&A
> where this topic is handled, but either in an insufficient way, not
> applicable to Django 2.0, or else.
> 
> Best ones:
> https://stackoverflow.com/questions/24027901/dynamically-loading-django-apps-at-runtime
> https://stackoverflow.com/questions/7933596/django-dynamic-model-fields
> 
> And my own question with no answer so far:
> https://stackoverflow.com/questions/51234829/dynamic-django-apps
> 
> So I began implementing my own way of handling this.
> 
> Let me first tell a "user story", so you can imagine what I mean.
> 
> My application should more or less be a framework that provides a
> loosely-coupled bunch of modules working together, with a dependency
> tree and versioning. There is a "core module", and others that depend
> on it (e.g. "notifications" etc.). Third party apps should be
> possible, and something like an "app store" should be created to
> dynamically download apps from within the program, and add that
> functionality to the main application.
> 
> So, my first approach was creating zip files with a predefined
> structure (models.py, schema.py, views.py, client stuff etc.), and
> tried to load this code during runtime. I soon realized that I had to
> re-implement most of the stuff Django does anyway, and doing
> migrations isn't an easy task when done barefoot.
> 
> I then changed my mind, and found the best way of having "dynamic
> plugins" is using "Django apps" as plugins.
> But: Django apps are not pluggable. They have to be inserted
> hardcodedly into INSTALLED_APPS to have a predictable order of
> loading. Yes, I've read
> https://groups.google.com/forum/#!searchin/django-developers/app-loading%7Csort:date/django-developers/_iggZzrYtJQ/FWFPgCflSnkJ
> - and I "kind of" understand the Django setup() process (see later).
> 
> I started to fiddle with INSTALLED_APPS, as recommended in
> Stackexchange etc., and dynamically searched a "plugins" directory to
> add some plugins into the list of other apps, just by extending
> INSTALLED_APPS. Django sees no difference, has no cache problems and
> happily loads all my plugins.
> 
> BUT: this is no way dynamic. First thing I recognized is: You can't
> simply call DB requests anywhere near the settings.py loading time.
> Because there is no DB at that moment, let alone models. I then
> stuffed the code into AppConfig.ready() of the core app, and was a
> step further, even if it's not recommended to call models there:
> I need to use models there: I want to check if a plugin app on disk is
> "deactivated", and NOT load it in that case. Aaaargh. Back to the
> start.
> 
> * In settings.py, you can tell Django to dynamically load plugins,
> using disk IO code there. BadIdea(tm).
> * in AppConfig.ready(), you can use models, even if discouraged, but
> it's too late to find "plugin apps" now and add it to INSTALLED_APPS.
> * in a middleware, you can use Models (somehow), but same problem.
> It's too late to add models.
> 
> I at least managed to add this plugins' URLs to my main u

Re: Dynamic app loading

[Raphael Michel]

Hi,

Am Tue, 31 Jul 2018 23:18:32 +0200
schrieb Christian González :
> Whow, I'm quite impressed. Never stumbled upon that. I'll recommend
> that for some collegues (to use it...)

Thanks =)

> But about the internals: Nice, this was the first way I implemented
> that as well, and maybe I will come back to that again. You have to
> restart the server as well if you want to enable a plugin, right?

If by enable you mean installing (in our terminology), yes. Normally,
you need to do something like

pip install pretix-myfancyplugin
python -m pretix migrate
python -m pretix rebuild
systemctl restart pretix

rebuild is a custom management command that compiles translation files,
SASS files and compressed JS files.

> From a security POV, I thought: who hinders anyone to write malicious
> code and provide an entry point for your system? maybe in a library
> you install... (but this is merely a philosophic question... don't
> bother.)

Nobody. But if you pip-install a library with malicious intents, you
have lost anyways, since its setup.py will likely be executed during
install (or at least some of its code will be executed once you import
it) and it can do whatever it wants anyway.

> But it's now replaced by entry points discovery. I had this too, (and
> will maybe come back to it). Setuptools' entry points discovery is a
> bit slow, but for the server start that doesn't matter, it's just
> once. (except development, you'll have to restart your server often)
> Your entrypoint is e.g. "pretix_pages=pretix_pages:PretixPluginMeta"
> - I don't understand that - this is an inner class of PluginApp. How
> can you  access it directly via the entry point? But generally I
> understand the workflow.

The part after the : in the entrypoint is probably not used at all at
the moment. With the entry point, I get the Django app. Then, with the
Django app, I get the inner class from the app registry:
https://github.com/pretix/pretix/blob/0b167aaa2cf607adddf4fe96c3da55b160b95602/src/pretix/base/plugins.py#L24

> * How do you use signals? e.g.
> 
>     @receiver(footer_link, dispatch_uid="pages_footer_links")
> What does this mean? How do you pass this to your frontend? Could you
> describe this in just a few words?

These are basically standard Django signals, with only slight
modifications to be able to turn them off per-client:
https://docs.djangoproject.com/en/2.0/topics/signals/

I then use a few custom helpers like a custom template tag that allows
to call a signal directly from a template:

{% eventsignal event "path.to.signal" argument="value" ... %}

This is just to avoid repetitive code, however.

> I'd like to add channels to the mix as well to enable a Vue frontend.
> Instead of copying your code and forking the parts that I need, It
> would be better OpenSource practice to maybe build a "plugin system"
> that is a library and can be used of both - this is not very
> difficult IMHO, b'cause most of it is already there.
> 
> Just tell me what you think about it - I can live with both - I just
> think that stability is better if more projects rely on one library
> and find security flaws and bugs alternatively ;-)

It would be great to have a library based on the ideas in pretix that
others can depend on. I'm not sure if pretix itself could use it, since
some of the things we do in the plugin API are very domain-specific,
like allowing plugin URLs to specify if they should be available only
when a shop is enabled or always.

A generic library would need to behave a bit different in design, and
changing that now will be hard for pretix, since there are already >50
plugins out there.

That said, I'd love to see it and maybe even collaborate on it!

> I 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
therefore probably more flexible. Our approach is a bit more tied to
Django's internals and therefore makes some things easier, but some less
clean.

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 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/20180801093159.49fd646d%40tavi.localdomain.
For more options, visit https://groups.google.com/d/optout.


pgpUvNQYOfvvI.pgp
Description: Digitale Signatur von OpenPGP

Re: Adding a bulk_save method to models

[Raphael Michel]

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 new method. Currently the
> proposed name is "QuerySet.bulk_save()" but I think it's a bit
> confusing since it uses QuerySet.update(), not Model.save(). It works
> similarly to QuerySet.bulk_update() from
> https://github.com/aykut/django-bulk-update but the arguments are a
> bit different.
> 
> 
> Josh's comment on the PR: "Since this only works for instances with
> an pk, do you think that bulk_update would be a better name? The
> regular save() method can either create or update depending on pk
> status which may confuse users here."
> 
> And Tom's reply: "I considered this, but queryset.update() is the
> best 'bulk update' method. I didn't want to confuse the two, this is
> more about saving multiple model fields with multiple differing
> values, gene bulk_save. Open to changing it though."
> 
> 
> On Tuesday, January 23, 2018 at 7:38:18 AM UTC-5, Neal Todd wrote:
> >
> > Hi Tom,
> >
> > That's great, should be a helpful addition to core. Will follow the
> > ticket and PR.
> >
> > Neal
> >
> > (Apologies - I hadn't spotted that you'd already referenced 
> > django-bulk-update in your ticket when I left my drive-by comment!)
> >
> > On Monday, January 22, 2018 at 7:41:11 PM UTC, Tom Forbes wrote:  
> >>
> >> Hey Neal,
> >>
> >> Thank you very much for pointing that out, I actually found out
> >> about this package as I was researching the ticket - I wish I had
> >> known about this a couple of years ago as it would have saved me a
> >> fair bit of CPU and brain time!
> >>
> >> I think that module is a good starting point and proves that it’s 
> >> possible, however I think the implementation can be improved upon
> >> if we bring it inside core. I worked on a small PR to add this 
> >> 
> >>  
> >> and the implementation was refreshingly simple. It still needs
> >> docs, a couple more tests and to fix a strange error with sqlite
> >> on Windows, but overall it seems like a lot of gain for a small
> >> amount of code.
> >>
> >> Tom 
> >>
> >>
> >> On 22 January 2018 at 15:10:53, Neal Todd (ne...@torchbox.com)
> >> wrote:
> >>
> >> Hi Tom,
> >>
> >> A built-in bulk save that's more flexible than update would
> >> certainly be nice. Just in case you haven't come across it though,
> >> there is a package called django-bulk-update:
> >>
> >> https://github.com/aykut/django-bulk-update
> >>
> >> I've found it very useful on a number of occassions where update
> >> isn't quite enough but the loop-edit-save pattern is too slow to
> >> be convenient.
> >>
> >> Probably some useful things in there when considering the API and 
> >> approach.
> >>
> >> Cheers, Neal 
> >>
> >> On Friday, January 19, 2018 at 5:49:48 PM UTC, Tom Forbes wrote:   
> >>>
> >>> Hello all,
> >>>
> >>> I’d love for some feedback on an idea I’ve been mulling around
> >>> lately, namely adding a bulk_save method to Dango.
> >>>
> >>> A somewhat common pattern for some applications is to loop over a
> >>> list of models, set an attribute and call save on them. This
> >>> unfortunately can issue a lot of database queries which can be a
> >>> significant slowdown. You can work around this by using
> >>> ‘.update()’ in some cases, but not all.
> >>>
> >>> It seems it would be possible to use a CASE statement in SQL to
> >>> handle bulk-updating many rows with differing values. For example:
> >>>
> >>> SomeModel.object.filter(id__in=[1,2]).update(
> >>> some_field=Case(
> >>> When(id=1, then=Value('Field value for ID=1')),
> >>> When(id=2, then=Value('Field value for ID=2'))
> >>> )
> >>> )
> >>>
> >>> I’ve made a ticket for this here: 
> >>> https://code.djangoproject.com/ticket/29037
> >>>
> >>> I managed to get a 70x performance increase using this technique
> >>> on a fairly large table, and it seems it could be applicable to
> >>> many projects just like bulk_create.
> >>>
> >>> The downsides to this is that it can produce very large SQL
> >>> statements when updating many rows (I had MySQL complain about a
> >>> 10MB statement once), but this can be overcome with batching and
> >>> other optimisations (i.e the same values can use WHEN id IN (x,
> >>> y, z) rather than 3 individual WHEN statements).
> >>>
> >>> I’m imagining an API very similar to bulk_create, but spend any
> >>> time on a patch I thought I would ask if anyone have any feedback
> >>> on this suggestion. Would this be a good addition to Dango?
> >>>
> >>>
> >>> --  
> >> 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: Adding a database-agnostic JSONField into Django

[Raphael Michel]

Hi everyone,

I used the sprints at DjangoCon US to work on this issue in form of a 
third-party package. Mainly, I created a subclass of 
django.contrib.postgres.fields.JSONField that

   - includes code from django-mysql to work on MySQL 5.7+ as well
   - does some nasty hacks to even work on MariaDB 10.2.7+
   - gracefully falls back to storing JSON strings in a TextField on all 
   other databases

Unfortunately, the differences between the JSON implementations (especially 
between MariaDB and MySQL) seem to be quite large. Since my primary 
objective was to prove that it is possible to create a multi-database 
field, I resolved this mostly with some back-and-forth data conversion 
hacks, instead of searching for a clean solution. Not all features of the 
PostgreSQL version are possible on MySQL/MariaDB, but the most useful ones 
all are.

This would probably need a lot of cleaning up before considering to move it 
to Django core, and you'd likely also want to explore integrating 
Oracle/SQLite for that. I will probably not have time to do that, but if 
someone else wants to, this might provide a starting point.

Here's the repository: https://github.com/raphaelm/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 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/330b1ade-ab27-4135-9952-d6a188789c31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a database-agnostic JSONField into Django

[Raphael Michel]

Hi,

On Saturday, October 20, 2018 at 10:48:04 PM UTC+2, Adam Johnson wrote:
>
> The main thing is that MySQL added a binary JSON type, whilst MariaDB just 
> made the JSON type an alias for TEXT (plus the corollaries that implies): 
> https://mariadb.com/kb/en/library/json-data-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.

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 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/3d2e6bf8-aa2a-4ece-80bc-5867f8105e04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Raphael Michel]

Hi Sage, Hi everyone,

I lacked the time to read this mailing list in the past months, and
someone at DjangoCon Europe just pointed me to this thread, so just for
reference, I want to add some prior work that I did to the list:

At DjangoCon US and thereafter, I developed a third-party
implementation that does a little more than the ones that are more
well-known and mentioned in the proposal:

https://github.com/raphaelm/django-jsonfallback

django-jsonfallback supports native JSON fields on PostgreSQL, MariaDB
*and* MySQL (which are quite different in that regard). On all other
databases, it falls back to the behaviour of just storing strings in
text fields. Therefore, it's still different from what is being
proposed here, and also the implementation is quite unclean in the
sense that it needs to check for database backends on the level of
database fields. When implemented in core, 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 (PDT)
schrieb "Sage M.A." :

> Hello, everyone! My name is Sage. I'm a 19-year-old computer science 
> student from Indonesia. I'm planning to join the Google Summer of
> Code (GSoC) this year, and I want to contribute to Django. I have
> written a draft for my proposal in this gist 
> .
> I have submitted two small patches for Django, and I hope to
> contribute more in the future. Feedbacks are much appreciated, thanks!
> 

-- 
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/20190416114408.35c8afa4%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgp5YMkBtqawZ.pgp
Description: Digitale Signatur von OpenPGP

Problems with cache.get_or_set behaviour

[Raphael Michel]

Hi,

I just experienced the following behaviour and would like to ask for
your opinion whether I should file this as a bug or whether this is
intended behaviour. I today had the pleasure to work with a crashed
memcached deaemon that could not restart because of a permission
problem. In this case, django, using the backend
'django.core.cache.backends.memcached.MemcachedCache'
behaved as follows:

>>> cache.set("foo", "bar")
>>> cache.get("foo")

So it fails silently and all get calls will return None. That is
sensible behaviour if one does not want cache calls to raise
exceptions. However, when using the new get_or_set() method from Django
1.9, I got

>>> cache.get_or_set('foo', default='bar')
0

This really is suprising to me. For any reasonable usage I can think of,
I would expect get_or_set() to return the specified default value.

When looking at the implementation of BaseCache.get_or_set, one finds
that in the case of the value not existing, the value is saved
and returned as follows:

if val is None:
val = self.add(key, default, timeout=timeout, version=version) 
if val:
return self.get(key, default, version)
return val

I assume that the last get() call is there to prevent a possible
race condition with other processes that is updating the key right
after our add statement.

However, if val is for some reason not evaluating to True, the result
of add() is being returned. add() 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, otherwise I would have
prepared a patch.

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+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/20160228232625.0e613084%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpFdwc2qwCzG.pgp
Description: Digitale Signatur von OpenPGP

Suggestion: Context manager for translation.activate

[Raphael Michel]

Hi,

in my application, I regularly need to switch the active language for a
short period of time. A popular example would be that a German-speaking
user does something and I need to send out a notification to an
English-speaking user.

Cluttering the code with translation.activate() statements is certainly
not making the core more readable, which is why I'm now using a context
manager:

with language(other_user.locale):
send_mail()

language() is currently implemented in my project like this:

@contextmanager
def language(lng):
_lng = translation.get_language()
translation.activate(lng or settings.LANGUAGE_CODE)
try:
yield
finally:
translation.activate(_lng)

This turned out to be very convenient and readable and I'd wanted to ask
for your opinion if 

(a) something like this should be added to django
(b) 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 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/2016092014.62ef589e%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpxloUreQIqG.pgp
Description: Digitale Signatur von OpenPGP

Re: Suggestion: Context manager for translation.activate

[Raphael Michel]

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 :

> Hi,
> 
> in my application, I regularly need to switch the active language for
> a short period of time. A popular example would be that a
> German-speaking user does something and I need to send out a
> notification to an English-speaking user.
> 
> Cluttering the code with translation.activate() statements is
> certainly not making the core more readable, which is why I'm now
> using a context manager:
> 
> with language(other_user.locale):
> send_mail()
> 
> language() is currently implemented in my project like this:
> 
> @contextmanager
> def language(lng):
> _lng = translation.get_language()
> translation.activate(lng or settings.LANGUAGE_CODE)
> try:
> yield
> finally:
> translation.activate(_lng)
> 
> This turned out to be very convenient and readable and I'd wanted to
> ask for your opinion if 
> 
> (a) something like this should be added to django
> (b) 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 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/20160920141233.7d7036da%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpMEgAif2NZY.pgp
Description: Digitale Signatur von OpenPGP

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

[Raphael Michel]

Hi,

Am Tue, 4 Oct 2016 00:11:28 +0200
schrieb Markus Holtermann :
> Thanks for the draft, Tom. I'm a bit concerned that the different
> `url*()` functions you can import will become confusing. Can we have
> `regex_url()` (with chim for `url()`) -- as proposed -- and
> `simple_url()` instead?

yes, we should at all cost avoid two functions named url() that behave
differently. The proposed import paths look to similar to be easily
differentiated on first sight and I normally just type `url` and hit
Alt+Enter to have my IDE do an automatic lookup. I 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 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/20161004100240.3bfb0bb9%40arlen.
For more options, visit https://groups.google.com/d/optout.


pgpyxuu_DX6sg.pgp
Description: Digitale Signatur von OpenPGP

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

[Raphael Michel]

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 is a lazy
string and not a regular one.

Cheers
rami

-- 
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/20161023183840.36da34cb%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpvJXHU_ALwE.pgp
Description: Digitale Signatur von OpenPGP

Re: Model translation and meta options

[Raphael Michel]

Hi Claude,

I spent some time looking at the implementations out there and in one
of my projects I'm running a custom one, that uses yet another approach
(that I plan to release as a library some day).

It is not only that we are not yet ready to bless one of them, I have a
feeling that we never will, as they are incredibly different from each
other. 

django-parler, django-hvad and django-model-i18n use seperate tables to
store the data, which is cleaner from a database point of view but
requires more JOINs. The former two use custom model base classes, the
latter uses a registration-based approach.

django-model-translation uses seperate columns for the different
languages, thus working with a "static" set of languages and
requiring a migration if you add translation capabilities or
change the set of languages. On the other hand, it saves you a lot of
JOIN queries. It uses a registration-based approach to register models
with the system.

My project uses only a custom field type that stores the translated
contents in a JSONField-type thing. This has some downsides with
regards to indexing and searching (at least on non-Postgres) and is
less clean from the DB side but requires neither migrations for new
langages nor any additional JOINs. (And I believe it is very clean on
the Django-side as it just requires you to replace a CharField with an
I18nCharField, no custom base classes, no registration, etc.).

Each of those approaches has severe advantages and disadvantages and
more importantly, they are fundamentally different. I don't believe a
new meta option would help you in any way, as for some of them you'd
probably *still* need a custom model base class.

It also would not allow you to easily switch between them or have a
reusable app to be compatible with 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  (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/20170214145327.6c16263d%40arlen.
For more options, visit https://groups.google.com/d/optout.


pgpnFbYwH1Kt8.pgp
Description: Digitale Signatur von OpenPGP

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

[Raphael Michel]

Hi Bernhard,

fyi: a similar topic was recently discussed here[0].

My point of view:

I recently counted 19 packages for this purpose, six of them being
actively maintained. You already mentioned that there are two ways that
you can design the database layout (I argue there are three, but thats
nitpicky), but there are also multiple ways to design the Python-side
API.

And here's the point: For each and every of the available options,
there are really big disadvantages.

The JOIN approach is the cleanest database-wise but has its own
problems, for example it gets really messy when you want to deal with
multiple languages at the same time. Also, no implementation managed to
implement that without massively limiting the overall power of the ORM.

The "many columns" approach is bad, because it requires migrations
every time you want to change the supported languages and because it
might lead to very large data sets returned by the database -- but its
easier to work with multiple languages at the same time.

There are also two implementations (django-nece and django-i18nfield)
using a JSON-based approach which mixes some of the problems and
features of the other two approaches, but you give up some lookup or
filterting functionality.

There is absolutely no one-size-fits-all solution here in sight, not
even a works-for-90%-of-people soltion. That makes it really hard to
argue for one of them to be included in Django.

On DjangoCon Europe this year, I gave a talk comparing the six
maintained packages [1]. In an email earlier on this list [2] you can
find a very short summary of that. Unfortunately, the videos of
this conferences are not yet online. You can find my slides at [3],
although the Slides mostly contain the mere facts, and not the opinions
expressed in 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/raphaelm/data-internationalization-in-django

-- 
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/20170613191025.14fade39%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpVy13lQyhfG.pgp
Description: Digitale Signatur von OpenPGP